[Top][All Lists]

[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: Shannon Zhao
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt-acpi-build: drop _ADR entry from SPCR
Date: Thu, 06 Aug 2015 21:19:09 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 2015/8/6 20:28, Andrew Jones wrote:
On Thu, Aug 06, 2015 at 12:24:27PM +0100, Leif Lindholm wrote:
>The _ADR entry in SPCR is optional and redundant. The same information
>is already provided in _CRS (which is mandatory).
>Signed-off-by: Leif Lindholm<address@hidden>
>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
>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 
>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.

Actually, why was ADR used
the first time? It would be good to know the story there in case there
as a valid reason.


reply via email to

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