| Message ID | 20220228183355.9090-1-Jason@zx2c4.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | None | expand |
From: Ard Biesheuvel <ardb@kernel.org> Sent: Monday, February 28, 2022 2:47 PM > > On Mon, 28 Feb 2022 at 23:38, Michael Kelley (LINUX) > <mikelley@microsoft.com> wrote: > > > > From: Ard Biesheuvel <ardb@kernel.org> Sent: Monday, February 28, 2022 2:22 PM > > > > > > On Mon, 28 Feb 2022 at 23:14, Michael Kelley (LINUX) > > > <mikelley@microsoft.com> wrote: > > > > > > > > From: Jason A. Donenfeld <Jason@zx2c4.com> Sent: Monday, February 28, 2022 > > > 1:55 PM > > > > > > > > > > Hi Andy, > > > > > > > > > > On Mon, Feb 28, 2022 at 10:28 PM Andy Shevchenko > > > > > <andy.shevchenko@gmail.com> 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
Hi Michael, On 3/22/22, Michael Kelley (LINUX) <mikelley@microsoft.com> wrote: > From: Ard Biesheuvel <ardb@kernel.org> Sent: Monday, February 28, 2022 2:47 > PM >> >> On Mon, 28 Feb 2022 at 23:38, Michael Kelley (LINUX) >> <mikelley@microsoft.com> wrote: >> > >> > From: Ard Biesheuvel <ardb@kernel.org> Sent: Monday, February 28, 2022 >> > 2:22 PM >> > > >> > > On Mon, 28 Feb 2022 at 23:14, Michael Kelley (LINUX) >> > > <mikelley@microsoft.com> wrote: >> > > > >> > > > From: Jason A. Donenfeld <Jason@zx2c4.com> Sent: Monday, February >> > > > 28, 2022 >> > > 1:55 PM >> > > > > >> > > > > Hi Andy, >> > > > > >> > > > > On Mon, Feb 28, 2022 at 10:28 PM Andy Shevchenko >> > > > > <andy.shevchenko@gmail.com> 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 > Do you want to send a patch against the crng/random.git tree adding that new id? Jason
On Tue, 22 Mar 2022 at 20:59, Michael Kelley (LINUX) <mikelley@microsoft.com> wrote: > > From: Ard Biesheuvel <ardb@kernel.org> Sent: Monday, February 28, 2022 2:47 PM > > > > On Mon, 28 Feb 2022 at 23:38, Michael Kelley (LINUX) > > <mikelley@microsoft.com> wrote: > > > > > > From: Ard Biesheuvel <ardb@kernel.org> Sent: Monday, February 28, 2022 2:22 PM > > > > > > > > On Mon, 28 Feb 2022 at 23:14, Michael Kelley (LINUX) > > > > <mikelley@microsoft.com> wrote: > > > > > > > > > > From: Jason A. Donenfeld <Jason@zx2c4.com> Sent: Monday, February 28, 2022 > > > > 1:55 PM > > > > > > > > > > > > Hi Andy, > > > > > > > > > > > > On Mon, Feb 28, 2022 at 10:28 PM Andy Shevchenko > > > > > > <andy.shevchenko@gmail.com> 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?
From: Jason A. Donenfeld <Jason@zx2c4.com> Sent: Tuesday, March 22, 2022 1:12 PM > > Hi Michael, > > > > > 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 > > > > Do you want to send a patch against the crng/random.git tree adding that new id? I've sent a patch. Michael
From: Jason A. Donenfeld <Jason@zx2c4.com> Sent: Thursday, March 24, 2022 12:45 PM > > On 3/24/22, Michael Kelley (LINUX) <mikelley@microsoft.com> wrote: > > From: Ard Biesheuvel <ardb@kernel.org> Sent: Tuesday, March 22, 2022 3:07 > > PM > >> > >> On Tue, 22 Mar 2022 at 20:59, Michael Kelley (LINUX) > >> <mikelley@microsoft.com> wrote: > >> > > >> > 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? > > > > The Hyper-V team is looking into updating the spec. The document > > is 10 years old, so they need to find the original source for the PDF. > > > > Lol, here's the docx: > https://download.microsoft.com/download/3/1/C/31CFC307-98CA-4CA5-914C-D9772691E214/VirtualMachineGenerationID.docx Indeed! My mistake. I just assumed it was a PDF without even looking at it. :-( Somebody internally here also just commented that it was weird to have a .docx file posted for download. Regardless, that removes one hurdle to making updates! Michael
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];