Re: [PATCH kvmtool 1/5] arm64: Do not abort on register-dump failures

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 12/09/2026 15:02, Fuad Tabba wrote:
> On Sat, 12 Sept 2026 at 14:54, Fuad Tabba <fuad.tabba@linux.dev> wrote:
>>
>> Hi Suzuki,
>>
>> On Sat, 12 Sept 2026 at 08:33, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>
>>> On 31/08/2026 20:24, Fuad Tabba wrote:
>>>> kvm_cpu__show_registers() and kvm_cpu__show_code() read the vCPU's core
>>>> registers with KVM_GET_ONE_REG, and die() if the ioctl fails. Both are
>>>> diagnostics. They run from the KVM_EXIT_DEBUG case in kvm_cpu__start(),
>>>> from the "lkvm debug -d" dump path in handle_sigusr1(), and from the
>>>> panic dump in kvm_cpu_thread().
>>>>
>>>> Once a protected vCPU has run, its registers belong to the guest and
>>>> KVM_GET_ONE_REG returns -EPERM. Dying on that turns a diagnostic into a
>>>> VMM abort.
>>>
>>> Marc once suggested that these could always succeed with junk values for
>>> protected/Realm VMs. Do you think that is an option for pKVM ?
>>
>> It's possible, the host copy is still there, but I'd rather not. Once
>> the vCPU has run that copy is a mix rather than junk: the boot state
>> the VMM wrote, plus what the exit handlers copy out (the PSTATE mode,
>> x0 for an MMIO write, x0 to x2 for a forwarded PSCI call). A dump
>> would show a live PSTATE beside the PC from boot, and the VMM has no
>> way to distinguish them. With the error it prints that the state is
>> unavailable, which is what this patch does.
>>
>> It's also what the tree does for protected state elsewhere: s390
>> returns -EINVAL from KVM_GET/SET_ONE_REG on a protected VM, and x86
>> does the same from the register ioctls for the SEV-ES VM type, SNP and
>> TDX. Legacy SEV-ES is the one place that succeeds silently, kept for
>> backwards compatibility, and the commit that added the errors
>> (517987e3fb19) describes that as a problem. Sean's rationale for TDX:
>> KVM can't provide sane data, so it's userspace's job not to ask for it
>> [1].
>>

Thanks, I am aware of this. I will leave the decision to Marc.
For the record, for CCA we use GET_ONE_REG/SET_ONE_REG to configure
the SVE vector length, PMU Counter and the Debug HW BPRs and watch
points.
>>>
>>> If we go with this approach :
>>>
>>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>
>> Thanks, I'll add the tag. :)
> 
> Unless I misunderstood what "this" refers to exactly, please shout if
> that's the case, or continue the discussion :)

You got it right. I meant if we are happy to go with approach in the
patch.