-cpu host (was Re: [Qemu-devel] KVM call minutes for 2013-08-06)

[Peter Maydell <peter.maydell@linaro.org>]

[I missed this KVM call but the stuff about -cpu host ties into
an issue we've been grappling with for ARM KVM, so it seems
a reasonable jumping-off-point.]

On 6 August 2013 16:15, Juan Quintela <quintela@redhat.com> wrote:
> 2013-08-06
> ----------
>
> What libvirt needs/miss Today?
> - how to handle machine types? creating them inside qemu?
> - qemu --cpu help
>   only shows cpus,  not what features qemu will use
> - qemu -cpu host
>   what does this exactly means?  kvm removes same flags.
> - Important to know if migration would work.
> - Machine types sometimes disable some feature, so cpu alone is not
>   enough.

> - kernel removes some features because it knows it can't be virtualised
> - qemu adds some others because it knows it don't need host support
> - and then lots of features in the middle

So, coming at this from an ARM perspective:
Should any target arch that supports KVM also support "-cpu host"?
If so, what should it do? Is there a description somewhere of
what the x86 and PPC semantics of -cpu host are?

For ARM you can't get at feature info of the host from userspace
(unless you want to get into parsing /proc/cpuinfo), so my current
idea is to have KVM_ARM_VCPU_INIT support a target-cpu-type
which means "whatever host CPU is". Then when we've created the
vcpu we can populate QEMU's idea of what the CPU features are
by using the existing ioctls for reading the cp15 registers of
the vcpu.

The other unresolved thing is what "-cpu host" ought to mean
for the CPU's on-chip peripherals (of which the major one is
the interrupt controller) -- if the host is an A57 should
this imply that you always get the A57's GICv3, or is it OK
to provide an A57 with a GICv2? At the moment QEMU models the
per-cpu peripherals in a somewhat more semi-detached fashion
than is the case in silicon, treating them as more a part
of the board model than of the cpu itself. Having '-cpu host'
not affect them might be the pragmatic choice, since it fits
with what QEMU currently does and with kernel-side situations
where the host CPU may only be able to show the guest VM a
GICv2 view of the world (or only a GICv3, as the case may be).
For this to work it does require that guests figure out what
their per-cpu peripherals are by looking at the device tree
rather than saying "oh, this is an A57, I know all A57s
have this", of course...

-- PMM