Re: [PATCH 2/3 v6] ACPI: allow longer device IDs

[Andy Shevchenko]

On Tue, Mar 1, 2022 at 12:14 AM Michael Kelley (LINUX)
<mikelley@xxxxxxxxxxxxx> wrote:
> From: Jason A. Donenfeld <Jason@xxxxxxxxx> Sent: Monday, February 28, 2022 1:55 PM
> > 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.

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.

-- 
With Best Regards,
Andy Shevchenko