qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hw/arm/virt-acpi-build: drop _ADR entry from SP


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt-acpi-build: drop _ADR entry from SPCR
Date: Thu, 6 Aug 2015 15:00:41 +0100

On 6 August 2015 at 14:19, Shannon Zhao <address@hidden> wrote:
> On 2015/8/6 20:28, Andrew Jones wrote:
>> On Thu, Aug 06, 2015 at 12:24:27PM +0100, Leif Lindholm wrote:
>>> >So, this _ADR entry is only consumed by a set of not-widely-circulated
>>> >patches for the Linux kernel. And while the ARM Server Base Boot
>>> >Requirements specification mandates SPCR, it does not mandate this _ADR
>>> >entry.
>>> >
>>> >In the interest of not propagating non-standard extensions, I would be
>>> >really happy if we could consider dropping this from 2.4.
>>> >I do realize that this is a completely unreasonable request this late
>>> >in the release process, but I only spotted this yesterday, and it is a
>>> >very isolated change with very quantifiable effects.
>>> >
>>> >The patch
>>> > athttps://git.linaro.org/leg/acpi/leg-kernel.git/commitdiff/46eeec7b7332bdd104941703696d3812afd934c8
>>> >converts the non-upstream kernel SPCR handling code to use the _CRS
>>> >information instead.
>>
>> Grr... So when I saw how the kernel (the original non-upstream patch)
>> was using ADR, I presumed that that was a documented behavior. I guess
>> I should have confirmed that...
>>
>> While the kernel change makes sense, I'm not sure we want this QEMU
>> patch, as there*are*  kernels already using ADR. In the least I wouldn't
>> want to get burned twice, so I'd prefer to see the SPCR code actually
>> get into Linux first this time. That would also allow us to point at
>> something when we start breaking guests.
>
>
> I agree. It would be better after the kernel patch get into upstream kernel.

This kind of thing is why I was sceptical about accepting the ACPI
support patches before the ACPI code for everything went into the
upstream kernel :-(

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]