| Message ID | 20220228183355.9090-1-Jason@zx2c4.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | None | expand |
On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > From: Alexander Graf <graf@amazon.com> > > 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. > 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.
Hi Andy, On Mon, Feb 28, 2022 at 9:47 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > 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. Sorry, but no; that seems like a ridiculous requirement. There's virtual "hardware" out there that is behaving like this. It serves an important security function. There are no technical downsides to making the change. It works well. Yet you're upset that they didn't follow the rules. Indeed, tsk tsk on Microsoft. But that doesn't mean Linux users should suffer and have poorer security than Windows. This kind of thing happens all the time. We do our best to find the cleanest solution to the problem, and live with it. Linux isn't a one-hundred-per-cent-by-the-spec operating system, because the things it works with are often not one-hundred-per-cent-by-the-spec. We even have quirks tables. It's part of life. And in this case, the solution is so straightforward that it doesn't even require anything closely resembling a "hack" or a layering violation. And that space is already being used (zero filled) anyway because of struct padding. This fix is the "clean" way of doing it. Why make this harder than it needs to be? Jason
On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > From: Alexander Graf <graf@amazon.com> > > > > 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.
On Mon, Feb 28, 2022 at 10:02:43PM +0100, Ard Biesheuvel wrote: > On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > > > From: Alexander Graf <graf@amazon.com> > > > > > > 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. 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.
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? 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
Hi Andy, On 28.02.22 22:27, Andy Shevchenko wrote: > On Mon, Feb 28, 2022 at 10:02:43PM +0100, Ard Biesheuvel wrote: >> On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: >>> On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: >>>> From: Alexander Graf <graf@amazon.com> >>>> >>>> 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. > 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. While trying to revalidate whether this really is breaking the spec, I've tried to reread the respective section in it and I'm afraid that it may be valid use of the _CID identifier: """ 6.1.2 _CID (Compatible ID) This optional object is used to supply OSPM with a device’s Plug and Play-Compatible Device ID. Use _CID objects when a device has no other defined hardware standard method to report its compatible IDs. The _CID object is valid only within a Full Device Descriptor. An _HID object must also be present. Arguments: None Return Value: An Integer or String containing a single CID or a Package containing a list of CIDs A _CID object evaluates to either: * A single Compatible Device ID * A package of Compatible Device IDs for the device – in the order of preference, highest preference first. Each Compatible Device ID must be either: * A valid HID value (a 32-bit compressed EISA type ID or a string such as “ACPI0004”). * A string that uses a bus-specific nomenclature. For example, _CID can be used to specify the PCI ID. The format of a PCI ID string is one of the following: "PCI\CC_ccss" "PCI\CC_ccsspp" "PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss&REV_rr" "PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss" "PCI\VEN_vvvv&DEV_dddd&REV_rr" "PCI\VEN_vvvv&DEV_dddd" """ In this case, you could interpret things as looking at "bus-specific nomenclature" case which even in the examples mentioned in the spec exceeds the 8 character limit we impose on the matching logic today. There still is spec violation in Hyper-V's VMGenID device's _HID value which doesn't follow the PNP format, but that's not relevant here. _CID doesn't seem to have the same restrictions? 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
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. Michael > > 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) <mikelley@microsoft.com> 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:01, Alexander Graf <graf@amazon.com> wrote: > > Hi Andy, > > On 28.02.22 22:27, Andy Shevchenko wrote: > > On Mon, Feb 28, 2022 at 10:02:43PM +0100, Ard Biesheuvel wrote: > >> On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > >>> On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > >>>> From: Alexander Graf <graf@amazon.com> > >>>> > >>>> 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. > > 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. > > > While trying to revalidate whether this really is breaking the spec, > I've tried to reread the respective section in it and I'm afraid that it > may be valid use of the _CID identifier: > > > """ > > 6.1.2 _CID (Compatible ID) > > This optional object is used to supply OSPM with a device’s Plug and > Play-Compatible Device ID. Use _CID objects when a device has no other > defined hardware standard method to report its compatible IDs. The _CID > object is valid only within a Full Device Descriptor. An _HID object > must also be present. > > Arguments: > > None > > Return Value: > An Integer or String containing a single CID or a Package containing a > list of CIDs A _CID object evaluates to either: > > * > > A single Compatible Device ID > > * > > A package of Compatible Device IDs for the device – in the order of > preference, highest preference first. > > Each Compatible Device ID must be either: > > * > > A valid HID value (a 32-bit compressed EISA type ID or a string such > as “ACPI0004”). > > * > > A string that uses a bus-specific nomenclature. For example, _CID > can be used to specify the PCI ID. The format of a PCI ID string is > one of the following: > > "PCI\CC_ccss" "PCI\CC_ccsspp" > "PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss&REV_rr" > "PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss" "PCI\VEN_vvvv&DEV_dddd&REV_rr" > "PCI\VEN_vvvv&DEV_dddd" > > """ > > In this case, you could interpret things as looking at "bus-specific > nomenclature" case which even in the examples mentioned in the spec > exceeds the 8 character limit we impose on the matching logic today. > This is what I was referring to when I mentioned bus topology related metadata. This is why those uses of ACPI_ID_LEN outside of struct acpi_device_id may potentially be dangerous, given that _CIDs are apparently effectively unbounded in size. But relying on this to justify the "VM_GEN_COUNTER" CID is a bit of a stretch, IMO. > There still is spec violation in Hyper-V's VMGenID device's _HID value > which doesn't follow the PNP format, but that's not relevant here. _CID > doesn't seem to have the same restrictions? >
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.
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. :-( Michael
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.
Hi, On 2/28/22 19:33, Jason A. Donenfeld wrote: > From: Alexander Graf <graf@amazon.com> > > 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 <graf@amazon.com> > Cc: Rafael J. Wysocki <rafael@kernel.org> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Cc: Hans de Goede <hdegoede@redhat.com> > Cc: Len Brown <lenb@kernel.org> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Ard Biesheuvel <ardb@kernel.org> > Co-authored-by: Jason A. Donenfeld <Jason@zx2c4.com> > [Jason: reworked commit message a bit, went with len=16 approach.] > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> The need for this is a bit meh, but I have no objections against solving it this way: Acked-by: Hans de Goede <hdegoede@redhat.com> Regards, Hans > --- > 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];
Hi Hans,
On Tue, Mar 1, 2022 at 11:35 AM Hans de Goede <hdegoede@redhat.com> wrote:
> Acked-by: Hans de Goede <hdegoede@redhat.com>
Thanks for the Ack. I still need Rafael's Ack to take this through my
random.git tree, right? Or are you two one in the same when it comes
to that? Trying not to step on toes if possible.
Jason
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 <hdegoede@redhat.com> wrote: >> Acked-by: Hans de Goede <hdegoede@redhat.com> > > 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 <Jason@zx2c4.com> wrote: > > From: Alexander Graf <graf@amazon.com> > > 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 <graf@amazon.com> > Cc: Rafael J. Wysocki <rafael@kernel.org> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Cc: Hans de Goede <hdegoede@redhat.com> > Cc: Len Brown <lenb@kernel.org> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Ard Biesheuvel <ardb@kernel.org> > Co-authored-by: Jason A. Donenfeld <Jason@zx2c4.com> > [Jason: reworked commit message a bit, went with len=16 approach.] > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > --- > 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 <rafael.j.wysocki@intel.com> > 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, Mar 1, 2022 at 12:14 AM Michael Kelley (LINUX) <mikelley@microsoft.com> wrote: > From: Jason A. Donenfeld <Jason@zx2c4.com> Sent: Monday, February 28, 2022 1:55 PM > > 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. Yes, my point of 2) is targeting the following: a) MS should be notified b) MS must try very hard to avoid similar problems in the future, they very well may discuss the matters in ASWG with other companies c) the spec will be fixed for the future versions, while the current one will live for the backward compatibility only Frankly I'm a bit frustrated that it's not the first time MS violates the ACPI spec, while being a member of ASWG.
On Tue, Mar 01, 2022 at 11:35:12AM +0100, Hans de Goede wrote: > On 2/28/22 19:33, Jason A. Donenfeld wrote: > > Co-authored-by: Jason A. Donenfeld <Jason@zx2c4.com> Official tag is Co-developed-by > > [Jason: reworked commit message a bit, went with len=16 approach.] > > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
On Tue, Mar 1, 2022 at 3:26 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Tue, Mar 01, 2022 at 11:35:12AM +0100, Hans de Goede wrote: > > On 2/28/22 19:33, Jason A. Donenfeld wrote: > > > > Co-authored-by: Jason A. Donenfeld <Jason@zx2c4.com> > > Official tag is Co-developed-by Thanks, will adjust.
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: 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. Michael
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
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
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];