Re: [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 1 Mar 2021 15:27:38 +0100
Thomas Lamprecht <t.lamprecht@proxmox.com> wrote:

> On 01.03.21 15:20, Igor Mammedov wrote:
> > On Mon, 1 Mar 2021 08:45:53 +0100
> > Thomas Lamprecht <t.lamprecht@proxmox.com> wrote:  
> >> On 01.03.21 08:20, Michael S. Tsirkin wrote:  
> >>> There are various testing efforts the reason this got undetected is
> >>> because it does not affect linux guests, and even for windows
> >>> they kind of recover, there's just some boot slowdown around reconfiguration.
> >>> Not easy to detect automatically given windows has lots of random
> >>> downtime during boot around updates etc etc.
> >>>     
> >>
> >> No, Windows does not reconfigure, this is a permanent change, one is just lucky
> >> if one has a DHCP server around in the network accessible for the guest.
> >> As static addresses setup on that virtual NIC before that config is gone,
> >> no recovery whatsoever until manual intervention.  
> > Static IP's are the pain guest admin picked up to deal with so he might have to
> > reconfigure guest OS when it decides to rename NICs. In this case moving
> > to new QEMU is alike to updating BIOS which fixed PCI description.
> > (On QEMU side we try to avoid breaking changes, but sometime it happens anyway
> > and it's up guest admin to fix OS quirks)
> >   
> 
> heh, I agree, but users see it very differently, QEMU got updated, something
> stopped working/changed/... -> QEMU at fault.
lets try to workaround it as Michael have suggested, i.e. old behavior for old
machine types.

> >> I meant more of a "dump HW layout to .txt file, commit to git, and ensure
> >> there's no diff without and machine version bump" (very boiled down), e.g., like
> >> ABI checks for kernel builds are often done by distros - albeit those are easier
> >> as its quite clear what and how the kernel ABI can be used.  
> > ACPI tables are not considered as ABI change in QEMU, technically tables that QEMU
> > generates are firmware and not version-ed (same like we don't tie anything to
> > specific firmware versions). 
> > 
> > However we rarely do version ACPI changes (only when it breaks something or
> > we suspect it would break and we can't accept that breakage), this time it took
> > a lot of time to find out that. We try to minimize such cases as every
> > versioning knob adds up to maintenance.
> > 
> > For ACPI tables changes, QEMU has bios-tables-test, but it lets us to catch
> > unintended changes only.
> > Technically it's possible to keep master tables for old machine versions
> > and test against it. But I'm not sure if we should do that, because some
> > (most) changes are harmless or useful and should apply to all machine
> > versions.
> > So we will end up in the same situation, where we decide if a change
> > should be versioned or not.

If you can come up with a test case for this issue, patches are welcome.

We probably should test PCI device enumeration on Windows,
as it's what's broken. Testing that in qtest (make check) is out of question,
but there are acceptance tests which run various guest OSes and provide tools
to interact with guest. Perhaps adding test there could work.
Though I don't know if there are Windows based guest images available for it.

I guess it's something to discuss with guys who work on CI/testing
infrastructure (CCed).
 
> OK, fair enough. Many thanks for providing some rationale!
> 
>