[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: G Gregory
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt-acpi-build: drop _ADR entry from SPCR
Date: Thu, 20 Aug 2015 11:48:07 +0100

On 20 August 2015 at 11:18, Leif Lindholm <address@hidden> wrote:
> On Thu, Aug 20, 2015 at 01:24:39AM +0100, Peter Maydell wrote:
>> On 6 August 2015 at 14:25, Andrew Jones <address@hidden> wrote:
>> > On Thu, Aug 06, 2015 at 01:55:14PM +0100, Leif Lindholm wrote:
>> >> On Thu, Aug 06, 2015 at 02:28:03PM +0200, Andrew Jones wrote:
>> >> > 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.
>> >>
>> >> So, if that's the way it has to be, that's the way it has to be.
>> >> I'd just prefer not having different pieces of firmware validating
>> >> different software behaviours for the same thing.
>> >
>> > Yeah, now it's messy. I'm actually OK with this QEMU patch, with regard
>> > to the downstream stuff that I'm involved with, but other downstreams
>> > may not be so flexible... We need Peter to chime in with his opinion,
>> > CCed.
>> Could somebody who understands ACPI and the ramifications
>> here let me know if I should apply this patch, please?
>> (since we're now post-2.4)
> I presume my opinion is clear, but I'm cc:ing some of the Linaro ACPI
> team.
> Graeme, Al - the patch in question is:
> https://www.mail-archive.com/qemu-devel%40nongnu.org/msg314356.html
Using _ADR for a non enumerable bus is undefined behaviour in the ACPI

How it is used in Redhats SPCR patch is IMO wrong becuase there is no
guarantee that _ADR will be defined for any MMIO device in DSDT.

I believe QEMU should not follow this just to make a non upstreamed
Redhat patch work.


reply via email to

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