Messages in this thread | | | Subject | Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume | From | Ian Campbell <> | Date | Mon, 18 Jul 2011 10:05:18 +0100 |
| |
On Mon, 2011-07-18 at 09:47 +0100, Jan Beulich wrote: > > @@ -960,6 +962,54 @@ > > } > > break; > > > > + case XEN_DOMCTL_setfeatures: > > + { > > + struct domain *d; > > + ret = -ESRCH; > > + if ( (d = rcu_lock_domain_by_id(op->domain)) != NULL ) > > + { > > + printk("dom%d set features[%d] = %#x\n", d->domain_id, op->u.setfeatures.submap_idx, op->u.setfeatures.submap); > > + > > + switch (op->u.setfeatures.submap_idx) { > > + case 0: > > + if ( !paging_mode_translate(d) ) > > ... this condition looks inverted to me.
Quite possibly. I only ever actually tested this with a dodgy PV in HVM container implementation.
> > + { > > + op->u.setfeatures.submap &= ~(1U<<XENFEAT_writable_page_tables); > > + op->u.setfeatures.submap &= ~(1U<<XENFEAT_auto_translated_physmap); > > + } > > + if ( !is_pvhvm_domain(d) ) > > + { > > + op->u.setfeatures.submap &= ~(1U<<XENFEAT_supervisor_mode_kernel); > > + } > > + > > + op->u.setfeatures.submap &= ~(1U<<XENFEAT_writable_descriptor_tables); > > Why do you turn this off unconditionally?
Unless you build the hypervisor with supervisor_mode_kernel=1 (i.e. never) then it does not support XENFEAT_writable_descriptor_tables. In fact XENFEAT_supervisor_mode_kernel should also be unconditionally cleared (the check is a remnant of the PV in HVM container stuff).
Note that XENFEAT_writable_descriptor_tables means that the guest kernel should not make pagetable pages RO at all, which is different from the hypervisor's support for writing to RO pagetables (i.e. emulating pagetable updates).
> > > + > > + /* XXX other features */ > > That's perhaps also the place holder where the passed in information > would actually get stored?
Yep ;-)
Ian.
| |