WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] RE: expose MWAIT to dom0

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: expose MWAIT to dom0
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Mon, 15 Aug 2011 16:25:33 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.xen@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Mon, 15 Aug 2011 01:26:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E48F10D02000078000513A3@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>
References: <625BA99ED14B2D499DC4E29D8138F15062D2E80D67@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CA6E8CF9.1F344%keir.xen@xxxxxxxxx> <625BA99ED14B2D499DC4E29D8138F15062D2E80DCA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E48F10D02000078000513A3@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxbIxfSLCfhDvHHTBGlMfA3HDwYUQAAEzhg
Thread-topic: [Xen-devel] RE: expose MWAIT to dom0
> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Monday, August 15, 2011 4:12 PM
> 
> >>> On 15.08.11 at 09:57, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> > So how about the change like below?
> >
> > emulate_forced_invalid_op:
> > -        __clear_bit(X86_FEATURE_MWAIT % 32, &c);
> > +        if ( !IS_PRIV(current->domain) || !xen_cpuidle )
> > +            __clear_bit(X86_FEATURE_MWAIT % 32, &c);
> 
> You'd break any Dom0 kernel that uses the flag to determine whether it
> can actually use the mwait/monitor instructions. I agree with Keir that

For those old kernels, then disable cpuidle to revert the effect.

> for this particular purpose the code ought to look at the real CPUID
> flag.
> 
> It should be possible to do this without changing non-Xen code, since
> the use of the instructions is additionally gated on CPUID leaf 5
> producing non-zero output. But again, the kernel has to do this for
> itself, the hypervisor shouldn't expose the feature flag.
> 

Even by using real CPUID, the point is that we either need make it into
cpu capability bits to avoid further change arch_acpi_set_pdc_bits, or
provide Xen's own arch_acpi_set_pdc_bits by looking at real CPUID
result directly. The former has same effect as having Xen expose mwait,
while the latter simply adds more changes to Linux code.

Somehow imho it's easier to switch to a newer Xen release than switching
to a newer dom0 kernel. The latter requires more validations. If we can
make changes in Xen, it's easier for existing deployment to workaround
this issue. Or else only next releases from various OSVs may have the
fix which has long days to go...

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel