On Tue, 27 May 2025 14:24:31 +0100,
Miguel Luis <[email protected]> wrote:
>
>
>
> > On 27 May 2025, at 12:02, Marc Zyngier <[email protected]> wrote:
> >
> > On Tue, 27 May 2025 12:40:35 +0100,
> > Miguel Luis <[email protected]> wrote:
> >>
> >> Hi Marc,
> >>
> >>> On 27 May 2025, at 07:39, Marc Zyngier <[email protected]> wrote:
> >>>
> >>> Hi Eric,
> >>>
> >>> On Tue, 27 May 2025 07:24:32 +0100,
> >>> Eric Auger <[email protected]> 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.
BEBKAC. You are asking for nested on a (virtual) machine that doesn't
support it, and the kernel tells you so with a warning. Try the same
thing on a physical machine that doesn't have NV, and observe the
result.
M.
--
Without deviation from the norm, progress is not possible.
