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". -- PMM
