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:wp...@windriver.com] > Sent: Monday, September 14, 2015 9:53 AM > To: edk2-de...@ml01.01.org > Cc: Laszlo Ersek; Igor Mammedov; Michael S. Tsirkin; Josh Triplett; Gal > Hammer; edk2-devel-01; Moore, Robert; qemu-devel@nongnu.org; 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" <m...@redhat.com> 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 > > edk2-de...@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > -- > ========================================================================== > === > -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, > wp...@windriver.com | Master of Unix-Fu - Wind River > Systems > ========================================================================== > === > "I put a dollar in a change machine. Nothing changed." - George Carlin > ========================================================================== > ===