> On 13. Mar 2026, at 13:33, Peter Maydell <[email protected]> wrote:
>
> On Fri, 13 Mar 2026 at 11:47, Alyssa Ross <[email protected]> wrote:
>>
>> Peter Maydell <[email protected]> writes:
>>> Looking a bit closer at this, it's a bit awkward that we're
>>> looking at a machine property in generic target/arm code.
>>
>> Isn't SMP a machine property that we're looking at just above?
>
> It's one of the ones in the base MachineState that exist for
> all boards.
>
>>> There is no guarantee that the machine is "virt" or that every
>>> KVM-supporting machine has a "virtualization" property, and
>>> the target/ code isn't really supposed to do board-specific stuff.
>>
>> FWIW: there's another arm board with the same property, which I think
>> would have the same requirements. That's why I chose to just check the
>> property rather than checking machine type — the idea being to establish
>> the convention that machines /do/ have a virtualization property where
>> it makes sense.
>>
>>> The board-independent way to say "are we trying to enable EL2" is
>>> to look at the CPU property has_el2. But the CPU isn't created at
>>> this point, so it's too early to do that here.
>>
>> I spent a day or so trying to make something involving has_el2 work, but
>> ultimately couldn't get anywhere with it.
>>
>>> Similar things where the early accelerator code wants information
>>> from the board we have handled with a method in MachineClass,
>>> like get_physical_address_range. We could do that here, but
>>> maybe it's a bit over-engineered? IDK.
>>
>> I'll give it a go and see if I can make it work.
>>
>>> There are other cases also where the virt board will error
>>> out for "KVM and some config we could do with TCG":
>>> * KVM + EL2 + GICv2
>>> * KVM + EL2 + kernel-irqchip=off
>>> * KVM + GICv2 but host hardware doesn't support GICv2 emulation
>>> * KVM + GICv3 but host hardware doesn't support GICv3 emulation
>>> * KVM + MTE but host hardware/kernel doesn't support MTE
>>>
>>> The first two are "always fails", but if we're going to have
>>> a mechanism for "figure out in kvm_arch_init what KVM features
>>> the board is going to want to enable" then it might be nice
>>> to also be able to use it for the last 3.
>>
>> I can try that.
>
> Thanks, that would be helpful. I don't really have any
> specific ideas about what kind of API might be best here.
>
> There are probably similar issues with the other accelerators,
> e.g. -accel hvf,tcg -machine virtualization=on
> also ought to fall back to TCG, and similarly with "picked
> a GIC version we can't handle with this accelerator”.
Hello,
Something to note about that (with HVF and KVM) is that there’s
also kernel-irqchip=off/on to take into mind. For example on a vGICv3-only
system you can still run GICv2 VMs with kernel-irqchip=off on KVM.
And for HVF once the hardware irqchip is merged kernel-irqchip=off
will remain there for (primarily) GICv2 usage.
