On Tue, Dec 15, 2015 at 05:01:39PM +0000, Peter Maydell wrote:
On 15 December 2015 at 16:57, Andre Przywara <[email protected]> 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
signature.asc
Description: PGP signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
