[libvirt] [RFC 0/5] Qemu: s390: Cpu Model Support

[Jiri Denemark]

On Wed, Nov 02, 2016 at 16:34:30 -0400, Jason J. Herne wrote:
...
> Patch #5 updates qemuBuildCpuModelArgStr's VIR_CPU_MODE_HOST_MODEL case. It
> seems like all archs except PPC64 do not support host model mode.

x86 supports host-model too, but ppc64 (mis)used the host-model mode in
a very specific way.

> Here is a list of outstanding things to do and some questions.
> 
> 1. virsh domcapabilities --emulatorbin flag
> 
> This works today if the command is passed --emulatorbin /usr/bin/qemu-kvm.
> If no emulatorbin is given then Libvirt seems to choose
> /usr/bin/qemu-system-s390x my system which does not have kvm enabled.

Does s390x still use the abandoned qemu-kvm name or is it just the
stupid shell wrapper which calls the real binary with -machine
accel=kvm? You say /usr/bin/qemu-system-s390x does not have kvm enabled,
does it mean you cannot use kvm with this binary at all or you need to
explicitly enable it with the -machine accel=kvm option?

> A kvm session is needed for s390 to properly compute the host model. A kvm
> session is only available for the qemu-kvm binary.

Right, and the series I sent for review yesterday changes our probing
code to use kvm if it is available.

> Is the answer to tell our users to always supply --emulatorbin with
> /usr/bin/qemu-kvm argument?

No it shouldn't be necessary, --emulatorbin is needed only if you want
to use a QEMU binary which libvirt does not know about.

> 2. virsh baseline and compare support.
> 
> Both of these commands, for s390 at least, will need to spin up a Qemu session
> with monitor to compute the result. The only place I see this done today is
> qemu_capabilities. Rather than blindly duplicate the code, I guess we should
> carve out some type of api for spinning up a monitor backed Qemu instance, yes?
> 
> Also, neither compare nor baseline have the --emulatorbin flag. So we'll either
> need to add them or find an alternate solution. Any thoughts on this?

Yes, we will probably need to add new APIs which would accept more
parameters, but I'd keep it for later.

> 3.Support host passthrough mode.
> 
> This essentially just means passing -cpu host to qemu. We know Qemu supports
> this for s390 today. But Libvirt claims it is not supported due to the
> following:
> 
>   In virQEMUCapsIsCPUModeSupported, our virt "type" is VIR_DOMAIN_VIRT_QEMU, and
>   not VIR_DOMAIN_VIRT_KVM.

Well, this should be correct, or is QEMU on s390 able to use -cpu host
in TCG mode?

Does "virsh domcapabilities --virttype kvm" report host-passthrough as
supported?

>   virttype comes from domCaps and is set here: qemuConnectGetDomainCapabilities()
>   The relevant code is:
>
>   if (qemuHostdevHostSupportsPassthroughLegacy() ||
>           qemuHostdevHostSupportsPassthroughVFIO())
>           virttype = VIR_DOMAIN_VIRT_KVM;
>       else
>           virttype = VIR_DOMAIN_VIRT_QEMU;
> 
> I'll admit, I have not been able to figure out why these checks are failing in
> my test environment, when I suspect they should be passing. But in my case it
> seems as though these relate to host device passthrough. How do they apply to
> cpu model passthrough. What am I missing?

They are not related at all. The code is just setting a default value
for virttype if the caller doesn't set it explicitly. The logic looks a
bit weird, but it doesn't really matter, since you can ask for the
virttype you need explicitly.

Jirka