Re: [Qemu-devel] [edk2] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

[Bill Paul]

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
=============================================================================