[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Current HVM acpi support is broken



Another update:
Qemu0.8.2 acpi table:
There is no apic mode _prt table and processor table in dsdt, that is
why smp linux boot only showing one vcpu,
That means acpi smp can not supported.
Regards,
Winston,


Wang, Winston L wrote:
> Hi Christian,
> 
> Attached please see two simple patches to allow only one acpi set to
> generate acpi info in guest firmware, and still need
> acpi_init_fix.patch to make acpi=1 working, so I just resend to you:  
> 
> Test result functional:
> 
> 1)With acpi_xen.patch to use xen acpi code:
>   A.Acpi rhel4u1 4 vcpu boot and showing acpi timer is accepted
>   B.Acpi XP boot and installation successful
> 
> 2)With acpiqemu082.patch to use qemu0.8.2 code:
>   A.Acpi rhel4u1 4 vcpu boot and showing acpi timer is accepted
>   B.Acpi XP boot and installation are both failed very early,
>    blue screen complain about this is non acpi complain BIOS...
> 
> Test for IDE DMA data transfer rate on UP rhel4u1 with acpi=1
>         (mb/sec): xen acpi                            qemu8.02
>         40.82                        31.23
>         42.25                        38.58
>         43.01                        38.66
>  It around 13-14% performance slow down using qemu0.8.2 acpi code.
> 
> I think it is too early to switch to qemu's acpi implementation,
> please review the patch and let us know what do you think. 
> 
> Regards,
> 
> Winston,
> 
> 
> 
> Wang, Winston L wrote:
>> Christian,
>> I haven't tried qemu0.8.2 acpi code yet.
>> Let me try to do the following:
>> 1)Create two patches, one qemu0.8.2 acpi only another for xen acpi
>> only 2)Test the two and compare the difference both in functional
>> and performance Thanks, Winston,
>> 
>> Christian Limpach wrote:
>>> On 8/8/06, Wang, Winston L <winston.l.wang@xxxxxxxxx> wrote:
>>>> Hi Christian, Ian and Kair,
>>>> 
>>>> I think current hvm acpi support is broken.
>>>> We noticed qemu to 0.82 with acpi support is introduced on changset
>>>> 10957, it is conflict with xen hvm acpi code, in ../ioemu/hw/cp.c
>>>> start from ln 860:
>>> 
>>> Yes, I tried to disable the acpi which comes with qemu 0.8.2 but I
>>> missed the 2nd call-site (acpi_bios_init).
>>> 
>>> To move forward:
>>> - does it work if you disable the call to acpi_bios_init?
>>> - can you compare the qemu acpi support to the acpi support you've
>>> provided and maybe merge some of it?
>>> 
>>> I don't feel strongly about using one or the other, I guess it would
>>> be good if we could leverage some of the qemu acpi work but maybe
>>> it's still quite immature? 
>>> 
>>>     christian
>>> 
>>>> 
>>>>     cmos_init(ram_size, boot_device, bs_table, timeoffset);
>>>> 
>>>>     /* using PIIX4 acpi model */
>>>>     if (pci_enabled && acpi_enabled)
>>>>         pci_piix4_acpi_init(pci_bus, piix3_devfn + 3);
>>>> 
>>>>     if (pci_enabled && usb_enabled) {
>>>>         usb_uhci_init(pci_bus, piix3_devfn + 2);
>>>>     }
>>>> 
>>>>     if (pci_enabled && acpi_enabled && 0) {
>>>>         piix4_pm_init(pci_bus, piix3_devfn + 3);
>>>>     }
>>>> ...
>>>>     /* XXX: should be done in the Bochs BIOS */
>>>>     if (pci_enabled) {
>>>>         pci_bios_init();
>>>>         if (acpi_enabled)
>>>>             acpi_bios_init();
>>>>     }
>>>> }
>>>> 
>>>> The above code generate two acpi tables and acpi pci piix func3
>>>> device when acpi=1 in hvm guest platform.
>>>> 
>>>> Two sets of acpi can not co-exist:) What acpi set do we need to
>>>> keep? What is the advatage for that?
>>>> 
>>>> We are cureent have to use changset 10955 puls acpi_init_fix.patch
>>>> for acpi related development. 
>>>> 
>>>> Regards,
>>>> 
>>>> Winston,
>>>> 
>>>> _______________________________________________
>>>> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.