Hi Peter, On 13/04/18 16:06, Peter Maydell wrote: > 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 Oh OK. I did not know this was in place. At first sight, this looks simpler than (2) to me. I will investigate this solution.
Thanks! Eric > > (2) add an API to the kernel to make it easier to query it > for this sort of feature > > thanks > -- PMM >
