Re: [PATCH] KVM: arm64: Make the exposed feature bits in AA64DFR0_EL1 writable from userspace

[Marc Zyngier <maz@kernel.org>]

On Mon, 02 Dec 2024 08:03:26 +0000,
Eric Auger <eauger@redhat.com> wrote:
> 
> Hi Marc,
> 
> On 12/1/24 13:21, Marc Zyngier wrote:
> > Hey Eric,
> > 
> > On Thu, 28 Nov 2024 09:31:08 +0000,
> > Eric Auger <eauger@redhat.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> On 11/26/24 20:29, Marc Zyngier wrote:
> >>> Finally, who is going to ensure this keeps working in the foreseeable
> >>> future? Because while this is nice, that's not what gets deployed in
> >>> production, as it leads to unpredictable performances. My take is that
> >>> this thing will eventually bitrot and die.
> >> In the context of our works to define qemu vcpu models for ARM
> >> (https://lore.kernel.org/all/20241025101959.601048-1-eric.auger@redhat.com/)
> >> , our current approach is to try migrating between modern HW we have
> >> access to. The case above is migration between AmpereOne and Grace which
> >> both should be prevalent systems. Do you think this does not make sense
> >> at all to try migrating between those, alhough this may be challenging?
> > 
> > I don't mind the challenge. But I'm worried this is something that
> > looks like a reasonable idea that doesn't get any traction in
> > practice.
> > 
> > And the example you mention is pretty striking: who in their right
> > mind would migrate between these two systems? If you deploy a Grace
> > system, that's because you are making use of the GPU, and your VM is
> > likely to require it. Conversely, if you run on an Ampere system, you
> > don't want to use a valuable (read: bloody expensive) slot on a Grace
> > machine.
> 
> Yes I acknowledge it is a total valid point from a use case and cost
> point of view. I was expecting maybe some interest migrating between
> AmpereOne and Grace-Grace for farm enhancement but most probably it is
> marginal.

That's my understanding as well. Cloud vendors tend to have
homogeneous systems, and those who don't are realising that they shot
themselves in the foot (and in that case, the debug infrastructure is
the least of their worries).

> Definition of [qemu] named vcpu models looks pretty uneasy then because
> we don't have much relevant and accessible HW to test with, taking into
> account such non technical considerations. Besides migration within a
> CPU family I don't see much.

That's basically my point.

Another thing to consider is that there is an effort on the SBSA
front to standardise which breakpoint numbers are context-aware, which
would side-step the need for emulation in the long run (once the
current crop of HW is gone and forgotten, which should be in the next
3 months or so ;-).

But if there was a *credible* user coming out and saying that they
depended on this sort of feature to be supported now and forever, then
I'd be more supportive.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.