On Tue, Dec 15, 2015 at 05:01:39PM +0000, Peter Maydell wrote:
On 15 December 2015 at 16:57, Andre Przywara
<andre.przywara(a)arm.com> wrote:
> Even that wouldn't help us, I guess, as you cannot easily check for
> GICv3/GICv2 compatibility with a _script_. Having access to ioctl's make
> this pretty easy though: Just try to call KVM_CREATE_DEVICE with the
> proper type and get -ENODEV if this one is not supported. This can be
> done without any extra userland tool by just executing some ioctls on
> /dev/kvm (from C or using some helper library).
kvm-ok already runs a few external helper binaries for some
things. (Also you can do ioctls from a script if it's a perl
script ;-))
As you say the actual technical details of how to query for
the host's current supported functionality are straightforward,
so it's just a question of how libvirt is expecting that to be
exposed to it.
We currently probe the host features as well using som ioctls on
/dev/kvm, etc. There is no problem with adding any other probing. If
qemu can report what it supports, that's good too. So I see it from the
other side. It's straightforward to implement it in libvirt, so for me
it's just a question of how exactly should we do that. What should we
probe fr and also the outcome: what to (dis)allow for a domain.
thanks
-- PMM