On Fri, 29 Dec 2023 at 11:37, Marcin Juszkiewicz <marcin.juszkiew...@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
