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

[Laszlo Ersek <lersek@redhat.com>]

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" <mst@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.

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?

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.

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

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
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>