On 25.02.22 15:33, Jason A. Donenfeld wrote:
> On Fri, Feb 25, 2022 at 03:18:43PM +0100, Alexander Graf wrote:
>>> I recall this part of the old thread. From what I understood, using
>>> "VMGENID" + "QEMUVGID" worked /well enough/, even if that wasn't
>>> technically in-spec. Ard noted that relying on _CID like that is
>>> technically an ACPI spec notification. So we're between one spec and
>>> another, basically, and doing "VMGENID" + "QEMUVGID" requires fewer
>>> changes, as mentioned, appears to work fine in my testing.
>>>
>>> However, with that said, I think supporting this via "VM_Gen_Counter"
>>> would be a better eventual thing to do, but will require acks and
>>> changes from the ACPI maintainers. Do you think you could prepare your
>>> patch proposal above as something on-top of my tree [1]? And if you can
>>> convince the ACPI maintainers that that's okay, then I'll happily take
>>> the patch.
>>
>> Sure, let me send the ACPI patch stand alone. No need to include the
>> VMGenID change in there.
> That's fine. If the ACPI people take it for 5.18, then we can count on
> it being there and adjust the vmgenid driver accordingly also for 5.18.
>
> I just booted up a Windows VM, and it looks like Hyper-V uses
> "Hyper_V_Gen_Counter_V1", which is also quite long, so we can't really
> HID match on that either.
Yes, due to the same problem. I'd really prefer we sort out the ACPI
matching before this goes mainline. Matching on _HID is explicitly
discouraged in the VMGenID spec.
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879