From: Ard Biesheuvel <ardb@xxxxxxxxxx> Sent: Monday, February 28, 2022 2:47 PM
>
> On Mon, 28 Feb 2022 at 23:38, Michael Kelley (LINUX)
> <mikelley@xxxxxxxxxxxxx> wrote:
> >
> > From: Ard Biesheuvel <ardb@xxxxxxxxxx> Sent: Monday, February 28, 2022 2:22 PM
> > >
> > > On Mon, 28 Feb 2022 at 23:14, Michael Kelley (LINUX)
> > > <mikelley@xxxxxxxxxxxxx> wrote:
> > > >
> > > > From: Jason A. Donenfeld <Jason@xxxxxxxxx> Sent: Monday, February 28, 2022
> > > 1:55 PM
> > > > >
> > > > > Hi Andy,
> > > > >
> > > > > On Mon, Feb 28, 2022 at 10:28 PM Andy Shevchenko
> > > > > <andy.shevchenko@xxxxxxxxx> 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.
Michael
