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

["Wang, Winston L" <winston.l.wang@xxxxxxxxx>]

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

Attachment: acpi_xen.patch
Description: acpi_xen.patch

Attachment: acpi_init_fix.patch
Description: acpi_init_fix.patch

Attachment: acpi_qemu082.patch
Description: acpi_qemu082.patch

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