qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH for 6.2 v2 5/5] bios-tables-test: Update golden binaries


From: Thomas Lamprecht
Subject: Re: [PATCH for 6.2 v2 5/5] bios-tables-test: Update golden binaries
Date: Thu, 11 Nov 2021 14:47:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Thunderbird/95.0

On 11.11.21 12:32, Igor Mammedov wrote:
> On Thu, 11 Nov 2021 03:34:37 -0500
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
>> On Wed, Nov 10, 2021 at 04:11:40PM -0500, Igor Mammedov wrote:
>>> From: Julia Suvorova <jusual@redhat.com>
>>>
>>> The changes are the result of
>>>         'hw/i386/acpi-build: Deny control on PCIe Native Hot-Plug in _OSC'
>>> and listed here:
>>>
>>> Method (_OSC, 4, NotSerialized)  // _OSC: Operating System Capabilities
>>>              {
>>>                  CreateDWordField (Arg3, Zero, CDW1)
>>>                  If ((Arg0 == ToUUID 
>>> ("33db4d5b-1ff7-401c-9657-7441c03dd766") /* PCI Host Bridge Device */))
>>>                  {
>>>                      CreateDWordField (Arg3, 0x04, CDW2)
>>>                      CreateDWordField (Arg3, 0x08, CDW3)
>>>                      Local0 = CDW3 /* \_SB_.PCI0._OSC.CDW3 */
>>> -                    Local0 &= 0x1F
>>> +                    Local0 &= 0x1E
>>>
>>> Signed-off-by: Julia Suvorova <jusual@redhat.com>
>>> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
>>> ---
>>>  tests/qtest/bios-tables-test-allowed-diff.h |  16 ----------------
>>>  tests/data/acpi/q35/DSDT                    | Bin 8289 -> 8289 bytes
>>>  tests/data/acpi/q35/DSDT.acpihmat           | Bin 9614 -> 9614 bytes
>>>  tests/data/acpi/q35/DSDT.bridge             | Bin 11003 -> 11003 bytes
>>>  tests/data/acpi/q35/DSDT.cphp               | Bin 8753 -> 8753 bytes
>>>  tests/data/acpi/q35/DSDT.dimmpxm            | Bin 9943 -> 9943 bytes
>>>  tests/data/acpi/q35/DSDT.dmar               | Bin 0 -> 8289 bytes
>>>  tests/data/acpi/q35/DSDT.ipmibt             | Bin 8364 -> 8364 bytes
>>>  tests/data/acpi/q35/DSDT.ivrs               | Bin 8306 -> 8306 bytes
>>>  tests/data/acpi/q35/DSDT.memhp              | Bin 9648 -> 9648 bytes
>>>  tests/data/acpi/q35/DSDT.mmio64             | Bin 9419 -> 9419 bytes
>>>  tests/data/acpi/q35/DSDT.multi-bridge       | Bin 8583 -> 8583 bytes
>>>  tests/data/acpi/q35/DSDT.nohpet             | Bin 8147 -> 8147 bytes
>>>  tests/data/acpi/q35/DSDT.nosmm              | Bin 0 -> 8289 bytes
>>>  tests/data/acpi/q35/DSDT.numamem            | Bin 8295 -> 8295 bytes
>>>  tests/data/acpi/q35/DSDT.smm-compat         | Bin 0 -> 8289 bytes
>>>  tests/data/acpi/q35/DSDT.smm-compat-nosmm   | Bin 0 -> 8289 bytes
>>>  tests/data/acpi/q35/DSDT.tis.tpm12          | Bin 8894 -> 8894 bytes
>>>  tests/data/acpi/q35/DSDT.tis.tpm2           | Bin 8894 -> 8894 bytes
>>>  tests/data/acpi/q35/DSDT.xapic              | Bin 35652 -> 35652 bytes  
>> Why do we have all the new files?  What is going on here?
> I think new files are not necessary.
> 
> I can update patch if we decide to keep ACPI enabled by default.
> 
> So question is:
>   do we revert to native pcie or stay with apci hootplug for 6.2?
> 

FWIW, we had to add some compat handling in Proxmox VE for the original change
as we do not pin Linux VM machines between cold-starts (they normally do not 
care
much about some HW/CPU bits added/dropped/moved) and the change here messed a 
bit
with the guest OS network configuration, as systemd's predictable interface 
naming
changed the name from, e.g., enp18 to ens6p18.

I mean, we wondered a bit over the original change here and contemplated 
reverting
it in our downstream build. While we read the reasons got a report of any of 
that
problems happen from our upper 6 digit count of systems reporting to our repos.
Ultimately we did not went with the revert to avoid problems if this was QEMU's
way forward, wrong choice it seems, and it now additionally seems that ACPI 
hotplug
produces boot-loops in some guests with seabios and serial or no display.

Anyhow (sorry for the whole back-story/rambling), if QEMU reverts this for 6.2 I
think we'd pull the line now and revert it in our 6.1 build we plan to fully 
roll
out soon, to avoid this whole mess for most of our user base in the first 
place..


- Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]