[Top][All Lists]

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

Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support
Date: Thu, 27 Jul 2017 10:39:10 +0200


> > SeaBIOS is used with both modern and legacy OSes, and it doesn't
> > have
> > any knowledge about what kind of OS will be used.  If anything, I'd
> > argue that QEMU has more knowledge about the guest OS than SeaBIOS
> > does (due to command-line options like machine version).
> No, the machine type is independent from the guest OS.

Well, not really.  Old guests (winxp & older) don't do very well on pc.
 Modern ones are better served with q35, because they either don't boot
on pc (macos I think) or can use the features of the modern hardware,
like pci express.

I still like the idea to have pc machine type provide the older stuff. 
The hardware we emulate for the pc machine type is old enough that old
acpi versions should have no problems describing it.

> > A - It would require deploying SeaBIOS and QEMU in lock-step.  To
> > get
> >     this in for QEMU v2.10 would require making QEMU changes during
> >     the soft freeze and would require a SeaBIOS "stable" release
> > that
> >     introduces ACPI table manipulation.
> Yes.

Since the switch to qemu-generated acpi tables we were able to avoid
that kind of lockstep updates, I'd prefer to not loose that.

> > B - I don't have full confidence the proposed ACPI changes wont
> > expose
> >     a quirk in some obscure OS from the last 25 years.  If it does
> >     expose a quirk, any work-around would likely require deploying
> > a
> >     new SeaBIOS and QEMU in lock-step.
> Well, the solution is proposed by ACPI itself, and the worst that can
> happen is that some OS prefers the RSDT to the XSDT (which we already
> test on Windows 2000).
> > C - We'd be introducing "shared ownership" of the acpi
> > tables.  Some
> >     of the tables would be produced by QEMU and some of them by
> >     SeaBIOS.  Explaining when and why to future developers would be
> > a
> >     challenge.
> The advantage is that the same shared ownership is already present in
> OVMF.  The RSDP/RSDT/XSDT are entirely created by the firmware in

Hmm, seabios could do the same then, and we would not need a lockstep


reply via email to

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