qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support
Date: Wed, 26 Jul 2017 16:57:26 +0300

On Wed, Jul 26, 2017 at 03:30:20PM +0200, Igor Mammedov wrote:
> On Wed, 26 Jul 2017 15:10:40 +0200
> Paolo Bonzini <address@hidden> wrote:
> 
> > On 26/07/2017 15:08, Igor Mammedov wrote:
> > > On Tue, 25 Jul 2017 18:23:22 +0200
> > > Paolo Bonzini <address@hidden> wrote:
> > >   
> > >> On 25/07/2017 18:14, Laszlo Ersek wrote:  
> > >>>   "No regressions became apparent in tests with a range of Windows
> > >>>    (XP-10)"
> > >>>
> > >>> In theory, w2k falls within that range.    
> > >>
> > >> Nope, Windows 2000 is like NT 5.0, XP is like NT 5.1. :(
> > >>
> > >> One possibility is to fix it in SeaBIOS instead: if you get a 2.0 FADT
> > >> and an XSDT and no RSDT, it can build an RSDT and a 1.0 FADT itself,
> > >> patching the RSDT to point to it.
> > >>
> > >> It's a hack, but it's the only place I see to make it "just work".  And
> > >> it could be extended nicely in the future.
> > >>
> > >> All QEMU would have to do is to provide an XSDT _instead_ of an RSDT.  
> > > I'd support it, however it would break migrated guests with old BIOS
> > > image in RAM on reboot.  
> > 
> > Why?  Shouldn't the old ACPI tables get migrated together with the old
> > BIOS?  Or are they rebuilt after reset?
> they are rebuild on reset, but I've been wrong
> Looking at SeaBIOS something similar to your suggestion also should work,
>  if 
>     RsdpAddr = find_acpi_rsdp();
>  fails, current SeaBIOS falls back to its own ACPI tables.
> 
> but it seems that we don't even need to go to that extent,
> all user have to do is to use "-no-acpi" CLI option with QEMU
> for any SeaBIOS to fallback to embedded legacy ACPI tables.
> 
> Maybe we should just fix wiki
>   http://wiki.qemu.org/Windows2000
> to recommend using '-no-acpi' option when running w2k and
> leave PC machine at rev3 and mention it in release notes.
> 
> Opinions?

I really don't want to go back and have to support the builtin ACPI
tables. Not worth the small hassle of maintaining RSDP in QEMU.

At some point we will want to split up ACPI code, leave PC
alone and add stuff for Q35 only. Maybe not yet though.


> > Paolo
> > 
> > > Legacy users have an option to build SeaBIOS without ACPI from QEMU
> > > support by turning off CONFIG_FW_ROMFILE_LOAD (or use old SeaBIOS)
> > > which leads to using legacy tables included in SeaBIOS.
> > > Then mgmt layer above libvirt which knows what guest OS it's
> > > going to run can pick legacy BIOS image for it.
> > > 
> > > But the testing issue will still stay as normally it's not tested
> > > path.
> > > 
> > > PS:
> > > For now we are going to revert PC machine to rev1 and leave q35 at rev3
> > > as Michael suggested to keep both w2k and macos happy.
> > >   
> > >>
> > >> Paolo
> > >>  
> > >>> In practice, it is impossible to
> > >>> test *all* Windows versions against ACPI generator changes, even if you
> > >>> try to be thorough (which Phil was). One might not even *know about*
> > >>> "all" Windows versions. So people using w2k and similar should
> > >>> co-maintain the ACPI stuff and report back with testing on the fly;
> > >>> otherwise regressions are impossible to avoid.    
> > >>  
> > >   
> > 



reply via email to

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