On 20 August 2015 at 11:18, Leif Lindholm <leif.lindh...@linaro.org> wrote: > On Thu, Aug 20, 2015 at 01:24:39AM +0100, Peter Maydell wrote: >> On 6 August 2015 at 14:25, Andrew Jones <drjo...@redhat.com> 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 specification.
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. Graeme
