> On 27 May 2025, at 12:02, Marc Zyngier <m...@kernel.org> wrote:
>
> On Tue, 27 May 2025 12:40:35 +0100,
> Miguel Luis <miguel.l...@oracle.com> wrote:
>>
>> Hi Marc,
>>
>>> On 27 May 2025, at 07:39, Marc Zyngier <m...@kernel.org> wrote:
>>>
>>> Hi Eric,
>>>
>>> On Tue, 27 May 2025 07:24:32 +0100,
>>> Eric Auger <eric.au...@redhat.com> wrote:
>>>>
>>>> Now that ARM nested virt has landed in kvm/next, let's turn the series
>>>> into a PATCH series. The linux header update was made against kvm/next.
>>>>
>>>> For gaining virt functionality in KVM accelerated L1, The host needs to
>>>> be booted with "kvm-arm.mode=nested" option and qemu needs to be invoked
>>>> with: -machine virt,virtualization=on.
>>>
>>> Thanks for respinning this series.
>>>
>>> Do you have any plan to support the non-VHE version of the NV support
>>> (as advertised by KVM_CAP_ARM_EL2_E2H0)? It would allow running lesser
>>> hypervisors (such as *cough* Xen *cough*), which completely rely on
>>> HCR_EL2.E2H being 0?
>>>
>>
>> Something that pops up is early_kvm_mode_cfg trying to handle nested mode
>> while KVM_ARM_VCPU_HAS_EL2_E2H0 is set.
>
> Care to elaborate?
>
Say host is booted in nested mode (kvm-arm.mode=nested) and host's KVM supports
both KVM_CAP_ARM_EL2 and KVM_CAP_ARM_E2H0.
A L1 guest boots setting both KVM_ARM_VCPU_HAS_EL2 and
KVM_ARM_VCPU_HAS_EL2_E2H0 and guest kernel's command line state
kvm-arm.mode=nested.
This splats the kernel from early_kvm_mode_cfg along a malformed early option
message.
This is not related to this qemu integration though, should you take it
somewhere else,
please let me know?
Thanks
Miguel
> M.
>
> --
> Without deviation from the norm, progress is not possible.
