qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Shannon Zhao <shannon.zhao@linaro.org>
To: Andrew Jones <drjones@redhat.com>,
	Leif Lindholm <leif.lindholm@linaro.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt-acpi-build: drop _ADR entry from SPCR
Date: Thu, 06 Aug 2015 21:19:09 +0800	[thread overview]
Message-ID: <55C35ECD.6040704@linaro.org> (raw)
In-Reply-To: <20150806122803.GA3083@hawk.localdomain>



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<leif.lindholm@linaro.org>
>> >---
>> >
>> >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.

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

-- 
Shannon

  parent reply	other threads:[~2015-08-06 13:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 11:24 [Qemu-devel] [PATCH] hw/arm/virt-acpi-build: drop _ADR entry from SPCR Leif Lindholm
2015-08-06 12:28 ` Andrew Jones
2015-08-06 12:55   ` Leif Lindholm
2015-08-06 13:25     ` Andrew Jones
2015-08-07  7:17       ` Peter Maydell
2015-08-20  0:24       ` Peter Maydell
2015-08-20  1:17         ` Shannon Zhao
2015-08-20 10:18         ` Leif Lindholm
2015-08-20 10:48           ` G Gregory
2015-08-20 11:09             ` Shannon Zhao
2015-08-20 11:21               ` Leif Lindholm
2015-08-20 21:54                 ` Andrew Jones
2015-09-04 17:14                   ` Peter Maydell
2015-08-06 13:19   ` Shannon Zhao [this message]
2015-08-06 14:00     ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C35ECD.6040704@linaro.org \
    --to=shannon.zhao@linaro.org \
    --cc=drjones@redhat.com \
    --cc=leif.lindholm@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).