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: Daniel P. Berrange
Subject: Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support
Date: Wed, 26 Jul 2017 15:04:59 +0100
User-agent: Mutt/1.8.3 (2017-05-23)

On Wed, Jul 26, 2017 at 03:43:43PM +0200, Igor Mammedov wrote:
> On Wed, 26 Jul 2017 15:33:37 +0200
> Paolo Bonzini <address@hidden> wrote:
> 
> > On 26/07/2017 15:30, 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  
> > 
> > Hmm so we need this plus keeping old machine types fixed to rev1 and
> > RSDT.  Diffstat will get worse. :)
> Even though I'd prefer to tie revision switch to machine type+version,
> and kill rev1 support along with machine type when it's removed
> v1, https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg06822.html,

We're unlikely to be deleting machine types (and the features they
depend on) for as long as there's downstream vendors who need compat
with that vintage of features. So given RHEL lifetimes, a pc-2.8
machine type (and features it needs) will be around another 10-15
years. So making decisions based on an expectation of deleting
machine types any time soon is questionable.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

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