RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2011-06-15 at 09:11 +0100, Tian, Kevin wrote:
> > From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> > Sent: Tuesday, June 14, 2011 4:27 AM
> > 
> > One step further: the problem is that pr->pblk is not set, thus
> > acpi_processor_get_power_info_fadt fails.
> > Knowing this, I found an error in the ACPI_DEBUG output that
> > corresponds:
> > 
> > [   17.062739] processor_xen-0222 [00] xen_acpi_processor_get: Processor
> > [-1:0]
> > [   17.062902] processor_xen-0225 [00] xen_acpi_processor_get: No PBLK
> > (NULL address)
> 
> this looks a bit strange. how about the native log?
> 
> > 
> > It does this for all processors. pr_id is always -1, pr->acpi_id
> > counting up from 0 to 2.
> 
> what's your dom0 vcpu number? and how about physical cpu?

Wasn't there some oddity in the Xen ACPI PM support due to the
disconnect between VCPU and PCPU? I thought it resulted in some CPU id
or other being reported back as -1, in much this manner.

There's some tweaking of this stuff in e.g.
xen_acpi_processor_get_power_info(). But equally
xen_acpi_processor_get_info() has a bunch of cases for the != -1 case.

Does the dom0_vcpus_pin hypervisor option workaround this sort of thing?

This changeset refers to the -1 too:

commit 68320323a51c2378aca433c76157d9e66104ff1e
Author: Jiang, Yunhong <yunhong.jiang@xxxxxxxxx>
Date:   Tue Sep 14 14:41:52 2010 -0700

    xen/acpi: Add cpu hotplug support
    
    Add physical CPU hotplug support to origin/xen/next-2.6.32 branch.
    Please notice that, even with this change, the acpi_processor->id is
    still always -1. This is because several workaround in PM side depends
    on acpi_processor->id == -1. As the CPU hotplug logic does not depends
    on acpi_processor->id, I'd still keep it no changes.
    
    But we need change the acpi_processor->id in the future.
    
    Signed-off-by: Jiang, Yunhong <yunhong.jiang@xxxxxxxxx>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>

Ian.

> > Any help is welcome, but I will analyze further...
> 
> Current Dom0 depends on several Xen specific functions like 
> xen_acpi_get_power_info
> you mentioned earlier, which is a copy from native acpi_get_power_info with 
> xen
> specific tweaks added. there's possibility that in your environment general 
> ACPI code
> is changed which is not reflected in Xen specific versions. 
> 
> Thanks
> Kevin
> 
> > 
> > Carsten.
> > 
> > -----UrsprÃngliche Nachricht-----
> > Von: Carsten Schiers
> > Gesendet: Montag, 13. Juni 2011 15:22
> > An: ke.yu; kevin.tian
> > Cc: xen-devel
> > Betreff: AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> > 
> > >>I will try to boot native Linux in order to verify 100%
> > >> that the tables
> > >> are there.
> > >
> > >yes, that's interesting data to compare.
> > 
> > I have booted with a Live Linux and dumped acpi tables. Those are 100%
> > identical with those
> > I received from Dom0. I will now start looking into
> > acpi_processor_get_power_info_fadt And
> > check, why it is returning -ENODEV.
> > 
> > Carsten.
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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