Re: [PATCH 21/35] target/arm: Add FEAT_NV to max, neoverse-n2, neoverse-v1 CPUs

[Peter Maydell]

On Fri, 29 Dec 2023 at 11:37, Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:
>
> W dniu 18.12.2023 o 12:32, Peter Maydell pisze:
>
> > Enable FEAT_NV on the 'max' CPU, and stop filtering it out for the
> > Neoverse N2 and Neoverse V1 CPUs.  We continue to downgrade FEAT_NV2
> > support to FEAT_NV for the latter two CPU types.
>
> According to Neoverse-V1 TRM r1p2 it has FEAT_NV2. Similar with Neoverse-N2.

I'm not sure what you're trying to say here ? Yes, the V1 has
NV2, that's why we have to downgrade it to FEAT_NV for the moment
when we're emulating, because at this point in the series we
don't have FEAT_NV2 emulation. At the end of the series this downgrade
goes away, because at that point we can emulate FEAT_NV2.

>
> You wrote already:
>
> > in practice hypervisors such as KVM are going to require FEAT_NV2
> > and not bother to support the FEAT_NV-only case, so I have
> > implemented them one after the other in this single patchset.
> So maybe they both should be FEAT_NV2 and FEAT_NV will be left unused.
> Or enable FEAT_NV for V1 (as being older) and FEAT_NV2 on N2.

As usual, we emulate what the actual hardware has, to the extent
that we are able to. For both of these CPUs that's both FEAT_NV
and FEAT_NV2, and we enable emulation of each at the point in the
series when we've implemented it.

> This way if someone wants to test nested virtualization then both
> versions will be available without use of 'max' cpu.

In theory it might be nice to be able to emulate a pure FEAT_NV
CPU, but in practice I don't expect anybody to want to do that.
If anybody has a real use case for it we can add a -cpu suboption
later.

thanks
-- PMM