Re: [PATCH] KVM: arm64: nv: Set ISTATUS for emulated timers, If timer expired

[Marc Zyngier]

On Mon, 10 Feb 2025 18:26:48 +0000,
Eric Auger <eauger@xxxxxxxxxx> wrote:
> 
> Hi Marc,
> 
> On 2/7/25 7:38 PM, Marc Zyngier wrote:
> > On Fri, 07 Feb 2025 18:09:58 +0000,
> > Oliver Upton <oliver.upton@xxxxxxxxx> wrote:
> >>
> >> Hey,
> >>
> >> On Fri, Feb 07, 2025 at 05:45:33PM +0000, Marc Zyngier wrote:
> >>> I found at least one issue that could fail the migration. Before the
> >>> VM starts running, we limit the feature set to the subset we actually
> >>> support with NV.
> >>>
> >>> By doing this, we also change the value of IDreg fields that are not
> >>> writable, because they describe features that we don't support.
> >>> Obviously, that fails on restore.
> >>>
> >>> I need to have a think...
> >>
> >> We spoke about this a while ago (and I forgot til now), but I was
> >> wondering if we could use vCPU feature flags to describe NV, including
> >> the selection between FEAT_E2H0 and FEAT_VHE.
> >>
> >> I think this might match userspace expectations a bit more closely where
> >> the state of the ID registers after init gives the actual feature set
> >> supported by the VM.
> > 
> > I'm not sure that's enough. Let me give you an example:
> > 
> > My host has FEAT_XNX, described in ID_AA64MMFR1_EL1.XNX. For whatever
> > reason, we don't allow this field to be written to, even out of NV
> > context. This is odd, because for an EL1 VM, this field means nothing
> > at all.
> So the curprit fields for me look like
> 
> - ID_AA64MMFR1_EL1.XNX
> - ID_AA64DFR0_EL1.DoubleLock
> - ID_AA64PFR0_EL1.RAS

Right, that more or less matches what I see locally.

I adopted the following scheme:

- On top of the existing KVM_ARM_VCPU_HAS_EL2, we have a new
  KVM_ARM_VCPU_HAS_EL2_E2H0, which is only valid when the former is
  also set, and force the whole VM in E2H==0 mode (that's Oliver's
  idea above)

- The NV view of the ID registers is enforced at the point where we
  compute the limit values via the ID reg reset helper, instead of the
  post-init repainting

- Neither of ID_AA64MMFR1_EL1.VH or ID_AA64MMFR4_EL1.E2H0 are writable
  at all

- Only ID_AA64MMFR4_EL1.NV_frac is writable

The result is fairly small, but is of course quite an ABI breakage,
and I'm more than happy not to have merged it sooner. Maybe I should
wait another couple of years! ;-)

> This is still based on your nv-next branch from Jan 9
> https://github.com/eauger/linux/tree/nv_next_jan9_2025

Yeah, that's getting old now, specially given the nature of the bug
fixes that have been added.

I'll try to rebase everything on -rc2 with the latest fixes and the
new ABI by the end of the week, and we will take it from there.

Thanks,

	M.

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