Hi Alex,
On Sun, Feb 27, 2022 at 12:42:03PM +0100, Alexander Graf wrote:
> > To allow device drivers to match identifiers that exceed the 9 byte
> > limit, this simply ups the length to 16, just like it was before the
> > aforementioned commit. Empirical testing indicates that this
>
>
> This is only true for 64bit systems where padding automatically bloated
> to 9 byte array to 16. I still believe the patch is fine as it is, but
> there will be minor .rodata overhead on 32bit targets which you may want
> to quantify in the patch description.
Good point. So I just tried this out with a 32-bit i686 kernel and the
results are the same again for the size of vmlinux. I then ran `objdump
--headers` and looked at the size of the .rodata section, where it's
also the same. I'm not quite sure what to make of this, as it's not what
I was expecting, but I think I tested it right. So maybe we're lucky
here?
Jason
Hey again,
On Sun, Feb 27, 2022 at 1:43 PM Jason A. Donenfeld <[email protected]> wrote:
>
> Hi Alex,
>
> On Sun, Feb 27, 2022 at 12:42:03PM +0100, Alexander Graf wrote:
> > > To allow device drivers to match identifiers that exceed the 9 byte
> > > limit, this simply ups the length to 16, just like it was before the
> > > aforementioned commit. Empirical testing indicates that this
> >
> >
> > This is only true for 64bit systems where padding automatically bloated
> > to 9 byte array to 16. I still believe the patch is fine as it is, but
> > there will be minor .rodata overhead on 32bit targets which you may want
> > to quantify in the patch description.
>
> Good point. So I just tried this out with a 32-bit i686 kernel and the
> results are the same again for the size of vmlinux. I then ran `objdump
> --headers` and looked at the size of the .rodata section, where it's
> also the same. I'm not quite sure what to make of this, as it's not what
> I was expecting, but I think I tested it right. So maybe we're lucky
> here?
I tried a little harder to get _some_ difference on 32-bit, and
managed to get one by doing i386_defconfig and then switching off
modules to make all M into Y, and then compared sizes:
vmlinux: 25590780 -> 25598972, so a 0.032% increase.
bzImage: 8698944 -> 8699424, so a 0.0055% increase.
So it does increase, ever so slightly, but a) on 32-bit, and b) a
super, super tiny amount.
In other words, I still think this patch is very much a-okay. But very
eager to hear from Rafael on the approach.
Jason
+Mika, Andy and Hans in case they have something to add
On Mon, Feb 28, 2022 at 12:27 AM Jason A. Donenfeld <[email protected]> wrote:
>
> Hey again,
>
> On Sun, Feb 27, 2022 at 1:43 PM Jason A. Donenfeld <[email protected]> wrote:
> >
> > Hi Alex,
> >
> > On Sun, Feb 27, 2022 at 12:42:03PM +0100, Alexander Graf wrote:
> > > > To allow device drivers to match identifiers that exceed the 9 byte
> > > > limit, this simply ups the length to 16, just like it was before the
> > > > aforementioned commit. Empirical testing indicates that this
> > >
> > >
> > > This is only true for 64bit systems where padding automatically bloated
> > > to 9 byte array to 16. I still believe the patch is fine as it is, but
> > > there will be minor .rodata overhead on 32bit targets which you may want
> > > to quantify in the patch description.
> >
> > Good point. So I just tried this out with a 32-bit i686 kernel and the
> > results are the same again for the size of vmlinux. I then ran `objdump
> > --headers` and looked at the size of the .rodata section, where it's
> > also the same. I'm not quite sure what to make of this, as it's not what
> > I was expecting, but I think I tested it right. So maybe we're lucky
> > here?
>
> I tried a little harder to get _some_ difference on 32-bit, and
> managed to get one by doing i386_defconfig and then switching off
> modules to make all M into Y, and then compared sizes:
>
> vmlinux: 25590780 -> 25598972, so a 0.032% increase.
> bzImage: 8698944 -> 8699424, so a 0.0055% increase.
>
> So it does increase, ever so slightly, but a) on 32-bit, and b) a
> super, super tiny amount.
>
> In other words, I still think this patch is very much a-okay. But very
> eager to hear from Rafael on the approach.
Increasing the ACPI_ID_LEN value is fine with me, but the patch
changelog is not entirely accurate.
The ACPI subsystem uses struct acpi_device_id mostly (if not only) for
device ID matching and it is generally used for creating lists of ACPI
device IDs in drivers (and allow/deny lists etc). The device IDs
extracted from the ACPI tables can be longer than ACPI_ID_LEN.
This means that drivers cannot match device IDs longer than 8
characters (excluding the terminating 0), because the IDs in the lists
used by them for ID matching cannot be longer than this and not
because the ACPI subsystem is limited by that value.
Hi Rafael,
On Mon, Feb 28, 2022 at 7:19 PM Rafael J. Wysocki <[email protected]> wrote:
> Increasing the ACPI_ID_LEN value is fine with me, but the patch
> changelog is not entirely accurate.
>
> The ACPI subsystem uses struct acpi_device_id mostly (if not only) for
> device ID matching and it is generally used for creating lists of ACPI
> device IDs in drivers (and allow/deny lists etc). The device IDs
> extracted from the ACPI tables can be longer than ACPI_ID_LEN.
>
> This means that drivers cannot match device IDs longer than 8
> characters (excluding the terminating 0), because the IDs in the lists
> used by them for ID matching cannot be longer than this and not
> because the ACPI subsystem is limited by that value.
Thanks for your notes there. I think Ard more or less pointed out
something similar too. I'll amend the commit message, send a v2, and
hopefully this change is okay with Mika/Andy/Hans.
Regards,
Jason
From: Alexander Graf <[email protected]>
We create a list of ACPI "PNP" IDs which contains _HID, _CID, and CLS
entries of the respective devices. However, when making structs for
matching, we squeeze those IDs into acpi_device_id, which only has 9
bytes space to store the identifier. The subsystem actually captures the
full length of the IDs, and the modalias has the full length, but this
struct we use for matching is limited. It originally had 16 bytes, but
was changed to only have 9 in 6543becf26ff ("mod/file2alias: make
modalias generation safe for cross compiling"), presumably on the theory
that it would match the ACPI spec so it didn't matter.
Unfortunately, while most people adhere to the ACPI specs, Microsoft
decided that its VM Generation Counter device [1] should only be
identifiable by _CID with a value of "VM_Gen_Counter", which is longer
than 9 characters.
To allow device drivers to match identifiers that exceed the 9 byte
limit, this simply ups the length to 16, just like it was before the
aforementioned commit. Empirical testing indicates that this
doesn't actually increase vmlinux size on 64-bit, because the ulong in
the same struct caused there to be 7 bytes of padding anyway, and when
doing a s/M/Y/g i386_defconfig build, the bzImage only increased by
0.0055%, so negligible.
This patch is a prerequisite to add support for VMGenID in Linux, the
subsequent patch in this series. It has been confirmed to also work on
the udev/modalias side in userspace.
[1] https://download.microsoft.com/download/3/1/C/31CFC307-98CA-4CA5-914C-D9772691E214/VirtualMachineGenerationID.docx
Signed-off-by: Alexander Graf <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Mika Westerberg <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Co-authored-by: Jason A. Donenfeld <[email protected]>
[Jason: reworked commit message a bit, went with len=16 approach.]
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
Hi Rafael,
This patch is directed toward you specifically. The first and last patch
of the series this is part of have been through the ringer of review a
bit already and do not specifically require your attention, but we wound
up getting hung up on an ACPI ID matching API limitation. This patch
fixes that limitation with this patch that you see here, with a trivial
one line fix, which does require your attention.
The other patches will go through my random.git tree naturally, but
because those patches depend on this one here, in order to compile
without warnings (and be functional at all), it would be nice if you
would provide an "Acked-by" on it and permit me to /also/ take it
through my random.git tree (if it looks like a correct patch to you, of
course). This would make the merge logistics a lot easier. Plus it's a
small +1/-1 line change.
This v6 updates the commit message.
Please have a look and let me know what you think.
Thanks,
Jason
include/linux/mod_devicetable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 4bb71979a8fd..5da5d990ff58 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -211,7 +211,7 @@ struct css_device_id {
kernel_ulong_t driver_data;
};
-#define ACPI_ID_LEN 9
+#define ACPI_ID_LEN 16
struct acpi_device_id {
__u8 id[ACPI_ID_LEN];
--
2.35.1
On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko <[email protected]> wrote:
>
> On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld <[email protected]> wrote:
> >
> > From: Alexander Graf <[email protected]>
> >
> > We create a list of ACPI "PNP" IDs which contains _HID, _CID, and CLS
> > entries of the respective devices. However, when making structs for
> > matching, we squeeze those IDs into acpi_device_id, which only has 9
> > bytes space to store the identifier. The subsystem actually captures the
> > full length of the IDs, and the modalias has the full length, but this
> > struct we use for matching is limited. It originally had 16 bytes, but
> > was changed to only have 9 in 6543becf26ff ("mod/file2alias: make
> > modalias generation safe for cross compiling"), presumably on the theory
> > that it would match the ACPI spec so it didn't matter.
>
> > Unfortunately, while most people adhere to the ACPI specs, Microsoft
> > decided that its VM Generation Counter device [1] should only be
> > identifiable by _CID with a value of "VM_Gen_Counter", which is longer
> > than 9 characters.
>
> Then why do we not see the ECR from somebody to update the spec or to
> fix MS' abuse of it?
> I believe _this_ should be the prerequisite to the proposed change.
>
What exactly are you suggesting here? That the contributor of this
patch joins the UEFI forum as an individual adopter in order to get
the ACPI spec updated before we can advance with this patch? Or that
he works with Microsoft to get them to refrain from violating it?
I don't think that is reasonable or realistic. The kernel is already
riddled with UEFI and ACPI quirks that are only there because some
teams at MS don't take the ACPI spec too literally (which is why they
have their own AML compiler, for one), and PC vendors only care about
the Windows sticker, so they don't care about the ACPI spec either.
So I don't think this is the right time to get pedantic about this.
Our ACPI subsystem already deals with CIDs that are longer than 8
characters (which are btw permitted by the ACPI spec for bus topology
related metadata), the only thing being changed here is the ability to
actually match against such identifiers.
Hi Andy,
On Mon, Feb 28, 2022 at 10:28 PM Andy Shevchenko
<[email protected]> wrote:
> My point is that this is clear abuse of the spec and:
> 1) we have to enable the broken, because it is already in the wild with
> the comment that this is an issue
>
> AND
>
> 2) issue an ECR / work with MS to make sure they understand the problem.
>
> This can be done in parallel. What I meant as a prerequisite is to start doing
> 2) while we have 1) on table.
Oh, okay, that makes sense. If you want to get (2) going, by all means
go for it. I have no idea how to do this myself; Ard said something
about joining the UEFI forum as an individual something or another but
I don't think I'm the man for the job there. Is this something that
Intel can do with their existing membership (is that the right term?)
at the UEFI forum? Or maybe a Microsoft engineer on the list?
From my side, regarding (1), I'm basically just waiting for Rafael's
"Acked-by" (or an explicit nack) so I can put this in my tree and move
on.
Jason
On Mon, Feb 28, 2022 at 11:14 PM Michael Kelley (LINUX)
<[email protected]> wrote:
> the wild to consume the new identifier. As a result, at this point Hyper-V
> is not planning to change anything.
>
> It's a lousy state-of-affairs, but as mentioned previously in this thread,
> it seems to be one that we will have to live with.
I should note that QEMU and VMware also support this too. So, yea, I
guess that boat has sailed.
Should that Hyper-V team do the ECR thing Andy was talking about?
Jason
On Mon, 28 Feb 2022 at 23:14, Michael Kelley (LINUX)
<[email protected]> wrote:
>
> From: Jason A. Donenfeld <[email protected]> Sent: Monday, February 28, 2022 1:55 PM
> >
> > Hi Andy,
> >
> > On Mon, Feb 28, 2022 at 10:28 PM Andy Shevchenko
> > <[email protected]> wrote:
> > > My point is that this is clear abuse of the spec and:
> > > 1) we have to enable the broken, because it is already in the wild with
> > > the comment that this is an issue
> > >
> > > AND
> > >
> > > 2) issue an ECR / work with MS to make sure they understand the problem.
> > >
> > > This can be done in parallel. What I meant as a prerequisite is to start doing
> > > 2) while we have 1) on table.
> >
> > Oh, okay, that makes sense. If you want to get (2) going, by all means
> > go for it. I have no idea how to do this myself; Ard said something
> > about joining the UEFI forum as an individual something or another but
> > I don't think I'm the man for the job there. Is this something that
> > Intel can do with their existing membership (is that the right term?)
> > at the UEFI forum? Or maybe a Microsoft engineer on the list?
>
> My team at Microsoft, which works on Linux, filed a bug on this
> issue against the Hyper-V team about a year ago, probably when the issue
> was raised during the previous attempt to implement the functionality
> in Linux. I've talked with the Hyper-V dev manager, and they acknowledge
> that the ACPI entry Hyper-V provides to guest VMs violates the spec. But
> changing to an identifier that meets the spec is problematic because
> of backwards compatibility with Windows guests on Hyper-V that
> consume the current identifier. There's no practical way to have Hyper-V
> provide a conformant identifier AND fix all the Windows guests out in
> the wild to consume the new identifier. As a result, at this point Hyper-V
> is not planning to change anything.
>
> It's a lousy state-of-affairs, but as mentioned previously in this thread,
> it seems to be one that we will have to live with.
>
Thanks for chiming in.
Why not do something like
Name (_CID, Package (2) { "VM_GEN_COUNTER", "VMGENCTR" } )
?
That way, older clients can match on the existing _CID and new clients
can match on the spec compliant one.
From: Ard Biesheuvel <[email protected]> Sent: Monday, February 28, 2022 2:22 PM
>
> On Mon, 28 Feb 2022 at 23:14, Michael Kelley (LINUX)
> <[email protected]> wrote:
> >
> > From: Jason A. Donenfeld <[email protected]> Sent: Monday, February 28, 2022
> 1:55 PM
> > >
> > > Hi Andy,
> > >
> > > On Mon, Feb 28, 2022 at 10:28 PM Andy Shevchenko
> > > <[email protected]> wrote:
> > > > My point is that this is clear abuse of the spec and:
> > > > 1) we have to enable the broken, because it is already in the wild with
> > > > the comment that this is an issue
> > > >
> > > > AND
> > > >
> > > > 2) issue an ECR / work with MS to make sure they understand the problem.
> > > >
> > > > This can be done in parallel. What I meant as a prerequisite is to start doing
> > > > 2) while we have 1) on table.
> > >
> > > Oh, okay, that makes sense. If you want to get (2) going, by all means
> > > go for it. I have no idea how to do this myself; Ard said something
> > > about joining the UEFI forum as an individual something or another but
> > > I don't think I'm the man for the job there. Is this something that
> > > Intel can do with their existing membership (is that the right term?)
> > > at the UEFI forum? Or maybe a Microsoft engineer on the list?
> >
> > My team at Microsoft, which works on Linux, filed a bug on this
> > issue against the Hyper-V team about a year ago, probably when the issue
> > was raised during the previous attempt to implement the functionality
> > in Linux. I've talked with the Hyper-V dev manager, and they acknowledge
> > that the ACPI entry Hyper-V provides to guest VMs violates the spec. But
> > changing to an identifier that meets the spec is problematic because
> > of backwards compatibility with Windows guests on Hyper-V that
> > consume the current identifier. There's no practical way to have Hyper-V
> > provide a conformant identifier AND fix all the Windows guests out in
> > the wild to consume the new identifier. As a result, at this point Hyper-V
> > is not planning to change anything.
> >
> > It's a lousy state-of-affairs, but as mentioned previously in this thread,
> > it seems to be one that we will have to live with.
> >
>
> Thanks for chiming in.
>
> Why not do something like
>
> Name (_CID, Package (2) { "VM_GEN_COUNTER", "VMGENCTR" } )
>
> ?
>
> That way, older clients can match on the existing _CID and new clients
> can match on the spec compliant one.
I'll run this by the Hyper-V guys. I don't have the ACPI expertise to disagree
with them when they say they can't change it. :-(
Michael
Hi,
On 3/1/22 11:38, Jason A. Donenfeld wrote:
> Hi Hans,
>
> On Tue, Mar 1, 2022 at 11:35 AM Hans de Goede <[email protected]> wrote:
>> Acked-by: Hans de Goede <[email protected]>
>
> Thanks for the Ack. I still need Rafael's Ack to take this through my
> random.git tree, right?
Right.
> Or are you two one in the same when it comes
> to that? Trying not to step on toes if possible.
No, I'm the drivers/platform/x86 subsys maintainer and as such do a lot
with ACPI too, but Rafael is the ACPI subsys maintainer.
Regards,
Hans
On Mon, Feb 28, 2022 at 7:34 PM Jason A. Donenfeld <[email protected]> wrote:
>
> From: Alexander Graf <[email protected]>
>
> We create a list of ACPI "PNP" IDs which contains _HID, _CID, and CLS
> entries of the respective devices. However, when making structs for
> matching, we squeeze those IDs into acpi_device_id, which only has 9
> bytes space to store the identifier. The subsystem actually captures the
> full length of the IDs, and the modalias has the full length, but this
> struct we use for matching is limited. It originally had 16 bytes, but
> was changed to only have 9 in 6543becf26ff ("mod/file2alias: make
> modalias generation safe for cross compiling"), presumably on the theory
> that it would match the ACPI spec so it didn't matter.
>
> Unfortunately, while most people adhere to the ACPI specs, Microsoft
> decided that its VM Generation Counter device [1] should only be
> identifiable by _CID with a value of "VM_Gen_Counter", which is longer
> than 9 characters.
>
> To allow device drivers to match identifiers that exceed the 9 byte
> limit, this simply ups the length to 16, just like it was before the
> aforementioned commit. Empirical testing indicates that this
> doesn't actually increase vmlinux size on 64-bit, because the ulong in
> the same struct caused there to be 7 bytes of padding anyway, and when
> doing a s/M/Y/g i386_defconfig build, the bzImage only increased by
> 0.0055%, so negligible.
>
> This patch is a prerequisite to add support for VMGenID in Linux, the
> subsequent patch in this series. It has been confirmed to also work on
> the udev/modalias side in userspace.
>
> [1] https://download.microsoft.com/download/3/1/C/31CFC307-98CA-4CA5-914C-D9772691E214/VirtualMachineGenerationID.docx
>
> Signed-off-by: Alexander Graf <[email protected]>
> Cc: Rafael J. Wysocki <[email protected]>
> Cc: Mika Westerberg <[email protected]>
> Cc: Andy Shevchenko <[email protected]>
> Cc: Hans de Goede <[email protected]>
> Cc: Len Brown <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Co-authored-by: Jason A. Donenfeld <[email protected]>
> [Jason: reworked commit message a bit, went with len=16 approach.]
> Signed-off-by: Jason A. Donenfeld <[email protected]>
> ---
> Hi Rafael,
>
> This patch is directed toward you specifically. The first and last patch
> of the series this is part of have been through the ringer of review a
> bit already and do not specifically require your attention, but we wound
> up getting hung up on an ACPI ID matching API limitation. This patch
> fixes that limitation with this patch that you see here, with a trivial
> one line fix, which does require your attention.
>
> The other patches will go through my random.git tree naturally, but
> because those patches depend on this one here, in order to compile
> without warnings (and be functional at all), it would be nice if you
> would provide an "Acked-by" on it and permit me to /also/ take it
> through my random.git tree (if it looks like a correct patch to you, of
> course). This would make the merge logistics a lot easier. Plus it's a
> small +1/-1 line change.
>
> This v6 updates the commit message.
Acked-by: Rafael J. Wysocki <[email protected]>
> Please have a look and let me know what you think.
>
> Thanks,
> Jason
>
> include/linux/mod_devicetable.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 4bb71979a8fd..5da5d990ff58 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -211,7 +211,7 @@ struct css_device_id {
> kernel_ulong_t driver_data;
> };
>
> -#define ACPI_ID_LEN 9
> +#define ACPI_ID_LEN 16
>
> struct acpi_device_id {
> __u8 id[ACPI_ID_LEN];
> --
> 2.35.1
>
On Tue, 22 Mar 2022 at 20:59, Michael Kelley (LINUX)
<[email protected]> wrote:
>
> From: Ard Biesheuvel <[email protected]> Sent: Monday, February 28, 2022 2:47 PM
> >
> > On Mon, 28 Feb 2022 at 23:38, Michael Kelley (LINUX)
> > <[email protected]> wrote:
> > >
> > > From: Ard Biesheuvel <[email protected]> Sent: Monday, February 28, 2022 2:22 PM
> > > >
> > > > On Mon, 28 Feb 2022 at 23:14, Michael Kelley (LINUX)
> > > > <[email protected]> wrote:
> > > > >
> > > > > From: Jason A. Donenfeld <[email protected]> Sent: Monday, February 28, 2022
> > > > 1:55 PM
> > > > > >
> > > > > > Hi Andy,
> > > > > >
> > > > > > On Mon, Feb 28, 2022 at 10:28 PM Andy Shevchenko
> > > > > > <[email protected]> wrote:
> > > > > > > My point is that this is clear abuse of the spec and:
> > > > > > > 1) we have to enable the broken, because it is already in the wild with
> > > > > > > the comment that this is an issue
> > > > > > >
> > > > > > > AND
> > > > > > >
> > > > > > > 2) issue an ECR / work with MS to make sure they understand the problem.
> > > > > > >
> > > > > > > This can be done in parallel. What I meant as a prerequisite is to start doing
> > > > > > > 2) while we have 1) on table.
> > > > > >
> > > > > > Oh, okay, that makes sense. If you want to get (2) going, by all means
> > > > > > go for it. I have no idea how to do this myself; Ard said something
> > > > > > about joining the UEFI forum as an individual something or another but
> > > > > > I don't think I'm the man for the job there. Is this something that
> > > > > > Intel can do with their existing membership (is that the right term?)
> > > > > > at the UEFI forum? Or maybe a Microsoft engineer on the list?
> > > > >
> > > > > My team at Microsoft, which works on Linux, filed a bug on this
> > > > > issue against the Hyper-V team about a year ago, probably when the issue
> > > > > was raised during the previous attempt to implement the functionality
> > > > > in Linux. I've talked with the Hyper-V dev manager, and they acknowledge
> > > > > that the ACPI entry Hyper-V provides to guest VMs violates the spec. But
> > > > > changing to an identifier that meets the spec is problematic because
> > > > > of backwards compatibility with Windows guests on Hyper-V that
> > > > > consume the current identifier. There's no practical way to have Hyper-V
> > > > > provide a conformant identifier AND fix all the Windows guests out in
> > > > > the wild to consume the new identifier. As a result, at this point Hyper-V
> > > > > is not planning to change anything.
> > > > >
> > > > > It's a lousy state-of-affairs, but as mentioned previously in this thread,
> > > > > it seems to be one that we will have to live with.
> > > > >
> > > >
> > > > Thanks for chiming in.
> > > >
> > > > Why not do something like
> > > >
> > > > Name (_CID, Package (2) { "VM_GEN_COUNTER", "VMGENCTR" } )
> > > >
> > > > ?
> > > >
> > > > That way, older clients can match on the existing _CID and new clients
> > > > can match on the spec compliant one.
> > >
> > > I'll run this by the Hyper-V guys. I don't have the ACPI expertise to disagree
> > > with them when they say they can't change it. :-(
> > >
> >
> > Yes, please, even if it makes no difference for this particular patch.
>
> The Hyper-V guys pass along their thanks for your suggestion. They have
> created an internal build with the change and verified that it preserves
> compatibility with Windows guests. I've tested with Linux guests and
> Jason's new driver (modified to look for "VMGENCTR"), and it all looks good.
> It will take a little while to wend its way through the Windows/Hyper-V
> release system, but they are planning to take the change.
>
Thanks for reporting back.
Will the spec be updated accordingly?