11:58 a.m.
On Tue, 2016-01-05 at 14:47 +0100, Christoffer Dall wrote:
> The tool is just a convenience for the administrator (and for higher
> level tools?), and it can't be where the validation happens for two
> reasons:
>
> - it doesn't take any argument, so it can't possibly know whether
> you're interested in running GICv2 or GICv3 guests
You don't need any input to report the capabilities of a host; either it
supports only GICv2, or only GICv3, or both.
But virt-host-validate doesn't report the capabilities of the host, it
just tells the user whether the host can be considered suitable for
running guests using a certain virtualization technology...
So I believe the check would be out of scope for the tool, as not
supporting GICv2 is not a host configuration error.
We already have facilities for reporting host capabilities (the output
of 'virsh capabilities') and that's where higher level tools should
look for GIC versions supported by the host.
> - libvirt needs to check before running the guest anyway
Why can libvirt not just run the tool and parse its output? That's what
I understood was done for other things, but perhaps I misunderstood.
It's the other way around: the tool uses libvirt to implement its
checks. Running a command and parsing its output makes sense when the
binary (as is the case for QEMU) is developed by a third party; if
you control both pieces, it's usually better to stick to C and avoid
spawning extra processes.
> Probing inside QEMU means libvirt can just ask it instead of
> implementing the checks itself, which means less code duplication;
> more importantly, this prevents the possibility of the checks ever
> going out of sync.
>
> > If I misunderstood, how would you like QEMU to report this?
>
> I'm not 100% sure about the best interface here (hopefully other people
> can weigh in) but I imagine there would be some sort of QMP command that
> lists the GIC versions supported by the QEMU binary, or some text in
> the output of 'qemu -help' that can be parsed to obtain such list.
ok, I don't think this is a big deal to implement, but I have no idea
which interface should be used.
Could you have a look at the libvirt side of things and figure out what
is done for similar things on x86 and we can see if we can implement
something like this for ARM in QEMU?
I realized the information is already sort of exposed by QEMU:
$ qemu-system-aarch64 -machine virt,?
...
virt.gic-version=string (Set GIC version. Valid values are 2, 3 and host)
...
Not the best format to parse, but the information is there. And we
already have some code to extract such parameters from QEMU using QMP's
query-command-line-options command![1]
Problem is, QEMU doesn't seem to be reporting machine type-dependent
parameters such as gic-version via QMP. Another problem is that, when we
probe using QMP, we launch QEMU using '-machine none'. I'm not sure
whether the former is a bug in QEMU or a design decision.
I'd like to hear more opinions on this, but I think a possible solution
would be for QMP to grow a query-gic-versions command that performs the
appropriate probing regardless of the machine type, and for libvirt to
start using it where available, falling back to accepting only 2, 3 and
host as valid values for all versions of QEMU older than 2.4.50 as it
currently does[2].
> > Should it
> > be the qemu binary directly or the script that Peter suggested?
>
> I think it should be the QEMU binary, especially since I assume QEMU
> itself will want to error out if an unsupported GIC version is requested
> by the user - there's no guarantee QEMU will be called by libvirt, so it
> will have to check on its own.
>
This is already done. If you try to create a VM which is not supported,
the system exits with an error.
Looks to me like creation of the requested device is attempted and an
error is reported on failure, which is not exactly the same as probing
in advance and aborting early if the operation is know to be impossible.
I might very well have missed something though, I'm far from being
familiar with QEMU's code :)
Cheers.
[1] It currently ignores everything but the parameter name; extending it
to look into the help text as well seems very doable
[2] Well, it really accepts all numeric values and doesn't accept the
string 'host', but that can be safely changed as other values never
worked to begin with
--
Andrea Bolognani
Software Engineer - Virtualization Team