| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume
|
To: |
Jan Beulich <JBeulich@xxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume |
|
From: |
Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> |
|
Date: |
Mon, 18 Jul 2011 10:05:18 +0100 |
|
Cc: |
"olaf@xxxxxxxxx" <olaf@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "keir@xxxxxxx" <keir@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Keir Fraser <keir.xen@xxxxxxxxx> |
|
Delivery-date: |
Mon, 18 Jul 2011 02:07:54 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4E240F3D020000780004DD70@xxxxxxxxxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
Organization: |
Citrix Systems, Inc. |
|
References: |
<CA499EDA.1E10E%keir.xen@xxxxxxxxx> <1310977905.20648.26.camel@xxxxxxxxxxxxxxxxxxxxxx> <4E240F3D020000780004DD70@xxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home