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

[Marc Zyngier <maz@kernel.org>]

On Thu, 16 Jan 2025 17:52:10 +0000,
Eric Auger <eauger@redhat.com> wrote:
> 
> Hi Marc,
> 
> On 1/14/25 4:52 PM, Marc Zyngier wrote:
> > On Tue, 14 Jan 2025 14:57:43 +0000,
> > Eric Auger <eauger@redhat.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> On 1/14/25 3:38 PM, Marc Zyngier wrote:
> >>> Hi Eric,
> >>>
> >>> On Tue, 14 Jan 2025 13:12:21 +0000,
> >>> Eric Auger <eauger@redhat.com> wrote:
> >>>>
> >>>> I also confirm that using a mailine edk2 fixed the issues I faced
> >>>> previously (fed/rhel L1 guest not booting).
> >>>>
> >>>> I used Marc's nv-next branch and qemu rebase.
> >>>
> >>> When did you sample this branch? It is almost daily rebased at the
> >>> moment, given that we keep piling up things in kvmarm/next.
> >> 5 days ago.
> > 
> > OK, so probably before I reapplied everything on top of kvmarm/next.
> > Not necessarily a bad thing, just slightly older. The core NV code
> > isn't rapidly changing anymore, with the exception of the recursive
> > nesting stuff that I am currently rewriting.
> > 
> >>
> >> If you want me to test a specific branch, please let me know, esp. in
> >> the context of latest series including
> >>
> >> [PATCH v2 00/17] KVM: arm64: Add NV GICv3 support
> > 
> > That'd be the current nv-next then, which has all the series currently
> > on the list, and a few more.
> > 
> >>>
> >>>> With a rhel L1 guest I can now boot buildroot, debian and rhel guest as
> >>>> L2 (feat mainline edk2). For rhel, I tested different kinds of page size
> >>>> combinations for L1/L2 (4k and 64kB) and it worked.
> >>>>
> >>>> I tested on AmpereOne and Grace-Hopper systems
> >>>
> >>> Thanks for the confirmation. I haven't had a chance to try QEMU yet,
> >>> but I expect that save/restore will not work. Something to look into,
> >> I have not tested this yet.I will give it a try.
> > 
> > Thanks, that'd be super helpful.
> 
> I confirm the migration fails when putting some registers on the dest
> side. I will further investigate.

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...

	M.

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