Re: [PATCH RESEND v2 0/6] target/arm: Add nested virtualization support

[Andrew Jones]

On Tue, Apr 27, 2021 at 01:15:24PM +0100, Peter Maydell wrote:
> 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.
>

Since these types of features seem to blur the line between being a CPU
and board property, then I think I'd prefer we call them CPU properties,
as they come from the CPU manual.

Also, if we'd rather not rework 'virtualization' to be a CPU property,
then we'll need libvirt to learn how to probe and set it, whereas if
it's a CPU property we just need to add it to
cpu_model_advertised_features[].

Whichever way we go, we should commit to it, at least for the foreseeable
future, otherwise libvirt and users will have to flipflop their approaches
as well (I'm assuming there have been limited users of this feature
without KVM and libvirt support, so less users would flipflop now than
later.)

I suggest we rework 'virtualization' now with this KVM support series and
'mte' with the series that brings its KVM support too. 'secure' doesn't
currently work with KVM, so it can probably wait until its KVM support
series comes along to be reworked.

Thanks,
drew