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] expose MWAIT to dom0

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] expose MWAIT to dom0
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 19 Aug 2011 16:34:18 +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@xxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Fri, 19 Aug 2011 01:35:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E4E369F0200007800051F2A@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: <4E4D23370200007800051D2C@xxxxxxxxxxxxxxxxxxxx> <625BA99ED14B2D499DC4E29D8138F15062EB8CC157@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4E4E369F0200007800051F2A@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxeR1088NzLIN/SRfKG04Mk3NCEDgAAyVpQ
Thread-topic: [Xen-devel] expose MWAIT to dom0
> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Friday, August 19, 2011 4:11 PM
> 
> >>> On 19.08.11 at 03:31, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> > OK, to avoid the regression, if it's really cared, then we may change Xen
> > to support entering C-state by mwait with interrupt enabled.
> 
> I don't think that's worth it.
> 
> > But the next question is whether it's really worthy of enabling Xen PM
> > such way:
> >     - I think native Linux only supports mwait with break-on-interrupt
> > extension too. You may confirm on such machines which I think should
> > have no C2/C3 available. It's less likely for a customer to try PM on a
> > platform where native Linux fails to do that
> 
> Looking at the code, I can't see why Linux wouldn't use the I/O method
> in this case instead.

acpi_processor_ffh_cstate_probe_cpu:
        /* mwait ecx extensions INTERRUPT_BREAK should be supported for C2/C3 */
        if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
            !(ecx & CPUID5_ECX_INTERRUPT_BREAK)) {
                retval = -1;
                goto out;
        }

arch_acpi_set_pdc_bits:
        /*
         * If mwait/monitor is unsupported, C2/C3_FFH will be disabled
         */
        if (!cpu_has(c, X86_FEATURE_MWAIT))
                buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);

> 
> >     - using mwait with interrupt enabled lacks the trace capability,
> > while w/o trace I don't think any customer would enable Xen PM w/o a
> > verification process.
> >
> > Another approach, if we really want to keep original I/O style, is to
> > reveal Xen's mwait related conditions in shared info page, say a simple
> > flag to indicate whether mwait bit should be set by pvops cpuid hook.
> > Xen will check mwait extension earlier before dom0 is launched, instead
> > of current point where dom0 registers cx info. This way there's no Xen
> > implementation detail encoded in dom0, while concerned regression
> > could be removed.
> 
> The concept sounds reasonable, just that the shared info page probably
> isn't the right mechanism (after all this is Dom0-only information that
> we want to expose). A new platform sub-hypercall would probably be
> the better route.
> 

yes, that's a better choice.

Thanks
Kevin

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