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

[Eric Auger]

Hi Marc,

On 2/7/25 6:45 PM, Marc Zyngier wrote:
> On Thu, 16 Jan 2025 17:52:10 +0000,
> Eric Auger <eauger@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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.
At first sight the registers we fail to put are
- ID_AA64PFR0_EL1
- ID_AA64DFR0_EL1
- ID_AA64MMFR1_EL1

I will add some traces in the kernel to figure out which fields cause issues

Eric

> 
> I need to have a think...
> 
> 	M.
>