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

[Michael S. Tsirkin]

On Mon, Mar 01, 2021 at 08:45:53AM +0100, Thomas Lamprecht wrote:
> On 01.03.21 08:20, Michael S. Tsirkin wrote:
> > On Mon, Mar 01, 2021 at 08:12:35AM +0100, Thomas Lamprecht wrote:
> >> On 28.02.21 21:43, Michael S. Tsirkin wrote:
> >>> Sure. The way to do that is to tie old behaviour to old machine
> >>> versions. We'll need it in stable too ...
> >>
> >> Yeah, using machine types is how its meant to be with solving migration
> >> breakage, sure.
> >> But that means we have to permanently pin the VM, and any backup restored 
> >> from
> >> that to that machine type *forever*. That'd be new for us as we always 
> >> could
> >> allow a newer machine type for a fresh start (i.e., non migration or the 
> >> like)
> >> here, and mean that lots of other improvements guarded by a newer machine 
> >> type
> >> for those VMs will.
> > 
> > If you don't do that, that is a bug as any virtual hardware
> > can change across machine types.
> 
> For us a feature, for fresh starts one gets the current virtual HW but for
> live migration or our live snapshot code it stays compatible. Works quite
> well here for many years, as we can simply test the HW changes on existing
> VMs - which failed here due to lack of static IPs in the test bed. So yes,
> it has its problems as it is not really  what an OS considers as HW change
> so big that it makes it a new device, mostly Windows is a PITA here as seen
> in this issue.
> 
> I mean, QEMU deprecates very old machines at some point anyway, so even then
> it is impossible to keep to the old machine forever, but otoh redoing some
> changes after a decade or two can be fine, I guess?
> 
> > 
> >> And yeah, stable is wanted, but extrapolating from the current stable 
> >> releases
> >> frequency, where normally there's maximal one after 5-6 months from the .0
> >> release, means that this will probably still hit all those distributions I
> >> mentioned or is there something more soon planned?
> >>
> >> Also, is there any regression testing infrastructure around to avoid such
> >> changes in the future? This change got undetected for 7 months, which can 
> >> be
> >> pretty the norm for QEMU releases, so some earlier safety net would be 
> >> good? Is
> >> there anything which dumps various default machine HW layouts and uses 
> >> them for
> >> an ABI check of some sorts?
> > 
> > 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.

Right, it so happened no one tested with a static IP.

> 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.

Exactly. We have such tests for ACPI which is what changed here.  We
just *do* change ACPI once in a while - it is code after all, and it is
normally fine to change as long as changes are not material.  So what do
we do  when we change it?  All we have right now is inspecting
it manually.

-- 
MST