From: Peter Maydell <peter.maydell@linaro.org>
To: Andrew Jones <drjones@redhat.com>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Andrea Bolognani" <abologna@redhat.com>,
qemu-arm <qemu-arm@nongnu.org>, "Haibo Xu" <haibo.xu@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [PATCH RESEND v2 0/6] target/arm: Add nested virtualization support
Date: Tue, 27 Apr 2021 13:15:24 +0100 [thread overview]
Message-ID: <CAFEAcA82VJqgD+B4gCr1M0n5oV869rBdoTzNS6xSs0f2f8iFvw@mail.gmail.com> (raw)
In-Reply-To: <20210427095458.3hbckyqbmfztcmge@gator.home>
On Tue, 27 Apr 2021 at 10:55, Andrew Jones <drjones@redhat.com> wrote:
>
> On Tue, Apr 27, 2021 at 10:42:18AM +0100, Peter Maydell wrote:
> > Why are we making the UI for "enable EL2 guest with KVM" different
> > from that for "enable EL2 guest with TCG" ? Currently an EL2
> > TCG guest is set up with "-M virt,virtualization=on", which then
> > does everything it needs to enable virtualization on all the
> > components on the board including the CPU.
> >
> > Unless there's a strong technical reason why KVM EL2 has to
> > be different, I think we should use the same switch.
>
> I agree we should use the same switch, but I think I'd prefer it be the
> CPU switch instead of the machine switch, as it's a CPU feature. There are
> some board properties too, like the maintenance interrupt, but we tend to
> call a feature a CPU feature when it shows up in the CPU manual, e.g. the
> PMU is also a CPU feature, even though it has a PPI.
This is mostly not how we've generally opted to handle this kind of thing on
the virt board where there is something that is not merely a CPU feature
but also has effects on the wider system: look at 'virtualization',
'secure' and 'mte'. Granted, the effects of 'virtualization' on the wider
system are less significant than those of 'secure' or 'mte' -- but I think
we implemented 'virtualization' on the same pattern as 'secure'.
If you want to propose changing how we handle those things, including
a backward-compatibility setup so we don't break existing command lines,
I guess we can have that discussion. But we should either *first* do that
change-of-course and *then* implement KVM EL2 to fit into that, or we should
just implement KVM EL2 to fit into the design we have today (and then do
the redesign later if we decide to do that). I don't think we should add
KVM EL2 support's command line switches using a new design that we haven't
committed to and which leaves it completely out of line with what the TCG
handling of the exact same feature is. And I don't feel strongly enough
that our current approach is wrong that I want to impose a "first do this
big rework" precondition on landing the KVM EL2 support.
thanks
-- PMM
next prev parent reply other threads:[~2021-04-27 12:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 12:55 [PATCH RESEND v2 0/6] target/arm: Add nested virtualization support Haibo Xu
2021-04-01 12:55 ` [PATCH RESEND v2 1/6] Update linux header with new arm64 NV macro Haibo Xu
2021-04-01 12:55 ` [PATCH RESEND v2 2/6] target/arm/kvm: Add helper to detect el2 when using KVM Haibo Xu
2021-04-27 8:27 ` Andrew Jones
2021-04-01 12:55 ` [PATCH RESEND v2 3/6] target/arm/kvm: Add an option to turn on/off el2 support Haibo Xu
2021-04-27 8:38 ` Andrew Jones
2021-04-27 9:29 ` Peter Maydell
2021-04-01 12:55 ` [PATCH RESEND v2 4/6] hw/intc/arm_gicv3: Enable support for setting vGIC maintenance IRQ Haibo Xu
2021-04-27 8:55 ` Andrew Jones
2021-04-01 12:55 ` [PATCH RESEND v2 5/6] target/arm/cpu: Enable 'el2' to work with host/max cpu Haibo Xu
2021-04-27 9:24 ` Andrew Jones
2021-04-27 9:38 ` Peter Maydell
2021-04-27 9:49 ` Andrew Jones
2021-04-27 12:04 ` Peter Maydell
2021-04-01 12:55 ` [PATCH RESEND v2 6/6] target/arm: Add vCPU feature 'el2' test Haibo Xu
2021-04-27 9:37 ` Andrew Jones
2021-04-01 17:53 ` [PATCH RESEND v2 0/6] target/arm: Add nested virtualization support Andrea Bolognani
2021-04-27 9:40 ` Andrew Jones
2021-04-27 9:42 ` Peter Maydell
2021-04-27 9:54 ` Andrew Jones
2021-04-27 12:15 ` Peter Maydell [this message]
2021-04-27 14:48 ` Andrew Jones
2021-04-27 14:58 ` Peter Maydell
2021-04-27 15:01 ` Peter Maydell
2021-04-27 16:17 ` Andrew Jones
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=CAFEAcA82VJqgD+B4gCr1M0n5oV869rBdoTzNS6xSs0f2f8iFvw@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=abologna@redhat.com \
--cc=drjones@redhat.com \
--cc=haibo.xu@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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).