On 13 April 2018 at 15:01, Auger Eric <eric.au...@redhat.com> wrote: > On 13/04/18 15:41, Peter Maydell wrote: >> I think it would be better to explicitly check "do we have >> support for split redistributors" rather than looking at >> KVM_MAX_VCPUS. It's not impossible that a distro kernel >> might have chosen to backport support for one but not the >> other. > > The issue is we have race here: > to check whether the new ATTR is supported I need to query the GICV3 KVM > device. This later is created in the GICv3 initialize. But to initialize > the VGIC I need the VCPUs to be created. And to create the VCPUs I need > to check their max number. Or do I miss somethinh? > > The KVM device create dry-run mode cannot be used here. I would need to > really create the KVM device and then delete it. The issue is there is > no kvm device DELETE ioctl at kernel level since KVM devices are deleted > on VM deletion if I understand correctly. Adding a KVM device delete at > kernel level may not be straightforward as I suspect some > simplifications could be made in KVM device deletion knowing the VM was > under deletion.
Two possibilities: (1) do like we do in kvm_arm_get_host_cpu_features() where we create a scratch VM to interrogate it and then throw it away when we have the info we need (2) add an API to the kernel to make it easier to query it for this sort of feature thanks -- PMM