qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [edk2] Windows does not support DataTableRegion at all


From: Moore, Robert
Subject: Re: [Qemu-devel] [edk2] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]
Date: Mon, 14 Sep 2015 18:04:14 +0000

I should say "some new things" are not supported, not all of them.


> -----Original Message-----
> From: Walz, Michael C
> Sent: Monday, September 14, 2015 10:24 AM
> To: Moore, Robert; Bill Paul; address@hidden
> Cc: Laszlo Ersek; Igor Mammedov; Michael S. Tsirkin; Josh Triplett; Gal
> Hammer; edk2-devel-01; address@hidden; Paolo Bonzini; Gough, Robert
> Subject: RE: [edk2] [Qemu-devel] Windows does not support DataTableRegion
> at all [was: docs: describe QEMU's VMGenID design]
> 
> Who are the Microsoft representatives in the ASWG? Shouldn't this
> conversation be happening with them?
> 
> -----Original Message-----
> From: Moore, Robert
> Sent: September 14, 2015 10:14
> To: Bill Paul; address@hidden
> Cc: Laszlo Ersek; Igor Mammedov; Michael S. Tsirkin; Josh Triplett; Gal
> Hammer; edk2-devel-01; address@hidden; Paolo Bonzini; Gough,
> Robert; Walz, Michael C
> Subject: RE: [edk2] [Qemu-devel] Windows does not support DataTableRegion
> at all [was: docs: describe QEMU's VMGenID design]
> 
> The Windows ACPI implementation doesn't even fully support ACPI 2.0 AFAIK,
> let alone other new things.
> 
> Rob Gough or Michael may know better than I do.
> 
> 
> > -----Original Message-----
> > From: Bill Paul [mailto:address@hidden
> > Sent: Monday, September 14, 2015 9:53 AM
> > To: address@hidden
> > Cc: Laszlo Ersek; Igor Mammedov; Michael S. Tsirkin; Josh Triplett;
> > Gal Hammer; edk2-devel-01; Moore, Robert; address@hidden; Paolo
> > Bonzini
> > Subject: Re: [edk2] [Qemu-devel] Windows does not support
> > DataTableRegion at all [was: docs: describe QEMU's VMGenID design]
> >
> > Of all the gin joints in all the towns in all the world, Laszlo Ersek
> > had to walk into mine at 03:24:42 on Monday 14 September 2015 and say:
> >
> > > On 09/14/15 10:24, Igor Mammedov wrote:
> > > > On Sun, 13 Sep 2015 15:34:51 +0300
> > > >
> > > > "Michael S. Tsirkin" <address@hidden> wrote:
> > > >> On Sun, Sep 13, 2015 at 01:56:44PM +0200, Laszlo Ersek wrote:
> > > >>> As the subject suggests, I have terrible news.
> > > >>>
> > > >>> I'll preserve the full context here, so that it's easy to scroll
> > > >>> back to the ASL for reference.
> > > >>>
> > > >>> I'm also CC'ing edk2-devel, because a number of BIOS developers
> > > >>> should be congregating there.
> > > >>
> > > >> Wow, bravo! It does look like we need to go back to the drawing
> > > >> board.
> >
> > I read your original post on this with great interest, and I applaud
> > your determination in tracking this down. Nice job. Sadly, it seems
> > you too have fallen victim to the "If It Works With Windows, It Must Be
> Ok"
> > syndrome.
> >
> > Now, I realize that as far as this particular situation is concerned,
> > even if Microsoft decided to add support for DataTableRegion()
> > tomorrow, it wouldn't really help because there are too many different
> > versions of Windows in the field and there's no way to retroactively
> patch them all.
> > (Gee, that sounds
> > familiar...)
> >
> > Nevertheless, am I correct in saying that this is in fact a bug in
> > Microsoft's ACPI implementation (both in their ASL compiler and in the
> > AML parser)? Unless
> > DataTableRegion() is specified to be optional in some way (I don't
> > know if it is or not, but I doubt it), this sounds like an clear cut
> > case of non- compliance with the ACPI spec. And if that's true, isn't
> > there any way to get Microsoft to fix it?
> >
> > -Bill
> >
> > > > I suggest we go back to the last Gal's series which is though not
> > > > universal but a simple and straightforward solution.
> > > > That series with comments addressed probably is what we need in
> > > > the end.
> > >
> > > I agree (I commented the same on the RHBZ too). The only one
> > > requirement we might not satisfy with that is that the page
> > > containing the generation ID must always be mapped as cacheable. In
> > > practice it doesn't seem to cause issues.
> > >
> > > We tried to play nice, but given that (a) the vmgenid doc doesn't
> > > mention a real requirement about the _CRS -- ie. no IO descriptors
> > > are allowed to be in it --, (b) Windows doesn't support
> > > DataTableRegion(), I doubt we could cover our bases 100% anyway.
> > > There can be any number of further hidden requirements, and hidden
> > > gaps in ACPI support too, so it's just business as usual with
> > > Windows: whatever works, works, don't ask why.
> > >
> > > Just my opinion of course.
> > >
> > > Laszlo
> > >
> > > >> The only crazy thing you didn't try is to use an XSDT instead of
> > > >> the DSDT.
> > > >> I find it unlikely that this will help ...
> > >
> > > _______________________________________________
> > > edk2-devel mailing list
> > > address@hidden
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> >
> > --
> > ======================================================================
> > ====
> > ===
> > -Bill Paul            (510) 749-2329 | Senior Member of Technical Staff,
> >                  address@hidden | Master of Unix-Fu - Wind River
> > Systems
> > ======================================================================
> > ====
> > ===
> >    "I put a dollar in a change machine. Nothing changed." - George
> > Carlin
> > ======================================================================
> > ====
> > ===



reply via email to

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