From: Paolo Bonzini <pbonzini@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
Paul Mundt <Paul.Mundt@huawei.com>,
Claudio Fontana <claudio.fontana@huawei.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Jani Kokkonen <Jani.Kokkonen@huawei.com>,
"tech@virtualopensystems.com" <tech@virtualopensystems.com>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation
Date: Wed, 12 Nov 2014 15:46:21 +0100 [thread overview]
Message-ID: <546372BD.1050705@redhat.com> (raw)
In-Reply-To: <20141112141059.GH28015@leverpostej>
On 12/11/2014 15:10, Mark Rutland wrote:
>>> We can't just pick-and-mix
>>> portions of ACPI and state that it's specified and standard.
>>
>> But that's what you already do if you want to build ACPI tables from DT.
>> You are already picking-and-mixing the variable portions of the ACPI
>> tables and make a DT bindings for them.
>
> I don't follow. I argued _against_ trying to build ACPI tables from DT
> because the two don't quite match up anyway. I argued _against_ trying
> to convert ACPI tables to DT in prior discussions for similar reasons.
Sorry, that was not you-Mark, but more you-ARM.
And in fact I'd tend to agree with you, but if there are people that
want not to use ACPI or UEFI or both, I think it's better if the UEFI
firmware swallows the same pill and builds ACPI from DT.
> In addition to fixing up the other specs which are affected by this
> (e.g. how we describe those additional CPUs). There's also some
> de-ACPIing to be done in addition to de-x86ification, and we need to be
> careful to ensure we have access to all the information we require in
> the absence of ACPI, and that we have a well defined behaviour on both
> sides of the interface for what would previously have been implicit in
> ACPI.
Yes, I agree. On the QEMU side the de-ACPIfication would have to be
done anyway (no GPE because of the reduced hardware), but you need extra
de-ACPIfication for stuff like the SRAT.
> I'm not saying that this is impossible. It's just a greater body of work
> than modifying one spec.
No doubt about that.
Paolo
next prev parent reply other threads:[~2014-11-12 14:47 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 17:43 [Qemu-devel] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation Alexander Spyridakis
2014-10-30 17:43 ` [Qemu-devel] [RFC PATCH 1/7] hw/i386: Move ACPI header definitions in an arch-independent location Alexander Spyridakis
2014-10-30 17:44 ` [Qemu-devel] [RFC PATCH 2/7] hw/arm/virt-acpi: Basic skeleton for dynamic generation of ACPI tables Alexander Spyridakis
2014-10-30 17:46 ` Peter Maydell
2014-10-30 17:52 ` [Qemu-devel] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation Peter Maydell
2014-10-30 18:02 ` [Qemu-devel] [Linaro-acpi] " Mark Rutland
2014-11-05 9:58 ` Claudio Fontana
2014-11-06 12:44 ` Peter Maydell
2014-11-06 12:57 ` Igor Mammedov
2014-11-06 13:33 ` Alexander Spyridakis
2014-11-06 13:52 ` Peter Maydell
2014-11-11 15:29 ` Mark Rutland
2014-11-11 16:31 ` Christoffer Dall
2014-11-11 16:48 ` Mark Rutland
2014-11-11 21:33 ` Christoffer Dall
2014-11-12 10:38 ` Mark Rutland
2014-11-12 10:44 ` Christoffer Dall
2014-11-12 10:55 ` Julien Grall
2014-11-12 11:07 ` Mark Rutland
2014-11-12 11:38 ` Graeme Gregory
2014-11-12 11:52 ` Paolo Bonzini
2014-11-12 12:04 ` Mark Rutland
2014-11-12 12:12 ` Paolo Bonzini
2014-11-12 13:27 ` Peter Maydell
2014-11-12 13:32 ` Paolo Bonzini
2014-11-12 15:01 ` Claudio Fontana
2014-11-12 15:32 ` Arnd Bergmann
2014-11-12 15:39 ` Peter Maydell
2014-11-12 15:52 ` Paolo Bonzini
2014-11-12 15:57 ` Arnd Bergmann
2014-11-12 16:04 ` Paolo Bonzini
2014-11-12 16:13 ` Arnd Bergmann
2014-11-12 16:25 ` Paolo Bonzini
2014-11-12 17:33 ` Peter Maydell
2014-11-13 8:32 ` Gerd Hoffmann
2014-11-13 8:14 ` Gerd Hoffmann
2014-11-13 8:10 ` Gerd Hoffmann
2014-11-13 18:16 ` Al Stone
2014-11-13 19:22 ` Paolo Bonzini
2014-11-14 7:54 ` Gerd Hoffmann
2014-11-12 9:08 ` Claudio Fontana
2014-11-12 10:56 ` Mark Rutland
2014-11-12 11:15 ` Arnd Bergmann
2014-11-12 11:34 ` Christoffer Dall
2014-11-12 11:48 ` Paolo Bonzini
2014-11-12 12:18 ` Mark Rutland
2014-11-12 12:27 ` Paolo Bonzini
2014-11-12 12:40 ` Christoffer Dall
2014-11-12 13:08 ` Arnd Bergmann
2014-11-12 13:27 ` Paolo Bonzini
2014-11-12 13:41 ` Mark Rutland
2014-11-12 13:59 ` Paolo Bonzini
2014-11-12 14:10 ` Mark Rutland
2014-11-12 14:46 ` Paolo Bonzini [this message]
2014-11-12 13:03 ` Arnd Bergmann
2014-11-12 13:35 ` Christoffer Dall
2014-11-12 11:55 ` Mark Rutland
2014-11-12 18:10 ` Peter Maydell
2014-11-13 9:57 ` Claudio Fontana
2014-11-17 17:52 ` Peter Maydell
2014-11-06 6:53 ` Hanjun Guo
2014-11-06 13:30 ` Mark Rutland
2014-11-06 13:33 ` Arnd Bergmann
2014-11-06 15:57 ` Paolo Bonzini
2014-11-06 16:18 ` Igor Mammedov
2014-11-06 16:27 ` Paolo Bonzini
2014-11-07 8:31 ` Hanjun Guo
2015-03-09 12:12 ` Leif Lindholm
2015-03-09 12:28 ` Peter Maydell
2015-03-09 12:47 ` Shannon Zhao
2015-03-09 14:50 ` Leif Lindholm
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=546372BD.1050705@redhat.com \
--to=pbonzini@redhat.com \
--cc=Jani.Kokkonen@huawei.com \
--cc=Paul.Mundt@huawei.com \
--cc=arnd@arndb.de \
--cc=christoffer.dall@linaro.org \
--cc=claudio.fontana@huawei.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=mark.rutland@arm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=tech@virtualopensystems.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.