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 11:20:28 on Monday 14 September 2015 and say:

> On 09/14/15 18:53, Bill Paul wrote:
> > 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.
> 
> Thank you!
> 
> > Sadly, it seems you too have
> > fallen victim to the "If It Works With Windows, It Must Be Ok" syndrome.
> 
> Well, I'd put it like this: we've fallen victim to a publicly
> undocumented feature gap / divergence from the ACPI spec in Windows'
> ACPI.SYS.
> 
> > 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...)
> 
> Correct.
> 
> > 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)?
> 
> Absolutely. You are absolutely right.
> 
> We implemented the VMGENID spec with some undeniable creativity, but it
> broke down because the AML interpreter in Windows does not support an
> ACPI 2.0 feature.
> 
> (That interpreter is supposed to be ACPI 4.0 compliant, minimally; at
> least if we can judge it after the "matching" AML.exe's stated
> compatibility level, which is ACPI 4.0 in the standalone download, and
> 5.0 if you get it as part of the WDK.)
> 
> > Unless
> > DataTableRegion() is specified to be optional in some way (I don't know
> > if it is or not, but I doubt it),
> 
> It's not, to the best of my knowledge.
> 
> > this sounds like an clear cut case of non-
> > compliance with the ACPI spec.
> 
> Yes, it's precisely that.
> 
> > And if that's true, isn't there any way to get
> > Microsoft to fix it?
> 
> I don't know. Is there?

You would think that someone at Intel would know someone at Microsoft that 
could put some wheels in motion. (All this technology and still we have 
trouble communicating. :P )
 
> Microsoft continue to release updates (KB*) for Windows 7, Windows 8,
> Windows 10, and I think rolling a fix out for those would cover our
> needs quite okay.
> 
> But:
> - This would force QEMU/KVM host users to upgrade their Windows guest.
>   Maybe not such a big hurdle, but I reckon Windows sysadmins are
>   really conservative about installing updates. Perhaps we could solve
>   this issue but documentation.

I agree with you that it's a hassle, but so is patching any other Windows bug. 
And while this particular use of DataTableRegion() affects VMs, it has bearing 
on bare metal installations too.
 
> - More importantly, how do I even *report* this bug? How do I convince
>   Microsoft to implement a whole missing feature in their ACPI compiler
>   and interpreter? Can I demonstrate business justification?
>
>   I'm doubtful especially because DataTableRegion's usefulness is quite
>   apparent to the ACPI developer in search for parametrization options.
>   DataTableRegion was published as part of ACPI 2.0, on July 27, 2000
>   (more than fifteen years ago). I simply cannot imagine that in all
>   that time *no* physical platform's firmware developer tried to use
>   DataTableRegion.
> 
>   Therefore I can't help but assume that some big BIOS developer
>   company has already reported this to Microsoft, and the feature
>   request has been rejected. So what chance would I have?

I understand what you're saying. But, there has to be some way to deal with 
these sorts of things. If everyone thinks and acts that way, then that's 
effectively letting Microsoft control the ACPI standard by "embracing and 
extending" it. (Or in this case I guess it's embracing and constricting it.)

I think a major part of the problem is that the only standard with which the 
big BIOS developers feel they must comply is the Windows Logo program. The x86 
market is still dominated by Windows users, and getting that Windows badge 
onto the machines is still top priority. If there was a UEFI Forum Logo 
program to which they had to adhere instead, things might be different. But 
even if you created one today, as long as the Windows Logo program is still 
around, I doubt the BIOS developers would bother with it, because the majority 
of the end users don't know or care if their PC actually complies with the 
UEFI or ACPI specs. Years of clever marketing have convinced them that If It 
Works With Windows, It Must Be Ok. That's what dictates how they spend their 
money, which is what dictates how much money the hardware vendors make, which 
is what dictates how much money the BIOS developers make, which is what makes 
time travel possible.

Or something like that.

Also, if you want to talk business cases, I'm assuming that somewhere 
Microsoft claims ACPI compliance. If so, then clearly that claim is untrue, 
and I'd be willing to bet this isn't the only place where their implementation 
deviates from the spec either. It's bad for business to claim compliance with 
an industry standard and then very obviously (and maybe even deliberately) not 
comply with it. (If, as you say, this has already been reported and Microsoft 
decided not to fix it, then it's no longer just a good faith mistake.) It's 
even worse to do that while also being a prominent member of the very same 
industry committee responsible for defining the standard in the first place.

In any case, bugs are bugs. You shouldn't need a justification to fix them, 
especially with iron-clad proof of their existence like you have here.

All that aside, I don't know who to report it to either. Maybe this is a good 
time to establish a way to do that, because I doubt this will be the last time 
it will be necessary.

-Bill

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