Bug 1178850

Is it safe if we allow enabling/disabling of all flags for all qemu versions or are there some restrictions?

What does "safe" mean in this context? I think if a flag is not supported, QEMU will just barf. But I don't know what's libvirt policy for the kind of configurations where users can shoot themselves in the foot, which is the case here I think.

I'm adding Eduardo do the CC list, he works in this area and can answer this kind of question better than me.

Unfortunately, the policy in libvirt is not to let people shoot themselves in the foot (sometimes I feel like it's half of the code), but mostly we are trying pretty hard to make sure that if we exec() qemu, it won't die on us and we can shout some reasonable error message at the user.

I just wanted to know whether, for example, qemu did not support this before 0.12 and you can specify all flags instead of invtsc (really bad example, but I hope you know what I was aiming for).

pmu=off support is something new. I can't tell exactly when it was introduced or how support for it can be detected. Eduardo, can you help us here?

The "pmu" option was introduced on QEMU v1.6.0, but can't be detected until we make the x86 CPU classes introspection-friendly (that's part of the work we need to do for bug 824987).

Now, about the initial request:

(In reply to Luiz Capitulino from comment #0)
> [...]. For real-time we need to disable the PMU and guarantee that the guest
> will use TSC deadline, to this end we have to pass the following
> command-line to QEMU:

If being careful about which features you expose is a requirement, why are you using -cpu host in the first place? Except for very new features that are unknown to QEMU, every feature exposed by -cpu host can be enabled by using a CPU model name that already has it and/or by enabling it explicitly in the command-line.

Using -cpu host was the easiest and simplest way to get started with real-time measurements. We may move away from it soon.

That's what <cpu mode='host-model'/> is for (and it already accepts modifying cpu flags).

Fixed upstream with v1.2.11-143-gadff345:

commit adff345e1ec9a6f528731ae40168a76b8e7620e0
Author: Martin Kletzander <mkletzan>
Date:   Mon Jan 5 17:03:58 2015 +0100

    qemu: Allow enabling/disabling features with host-passthrough

Try to verify this bug with libvirt-1.2.16-1.el7:

1. prepare a vm xml like this:

...

  <cpu mode='host-passthrough'>
    <feature policy='disable' name='tsc-deadline'/>
  </cpu>
...

2. start the guest and recheck the xml:

# virsh start test3
Domain test3 started

# virsh dumpxml test3

...
  <cpu mode='host-passthrough'>
    <feature policy='disable' name='tsc-deadline'/>
  </cpu>
...

3. check qemu command line:

... -cpu host,-tsc-deadline ...

4. test with require (seems there is some problem)

  <cpu mode='host-passthrough'>
    <feature policy='require' name='tsc-deadline'/>
  </cpu>

# ps axu|grep qemu
...-cpu host,+tsc-deadline...

however this is not right from doc:

require
    Guest creation will fail unless the feature is supported by host CPU.


And my host not support tsc-deadline:

# cpuid -1 |grep "time stamp counter"
time stamp counter deadline             = false

Also if if change the mode to 'host-model' will get error:

# virsh start test3
error: Failed to start domain test3
error: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: tsc-deadline


5. and test this xml will disappear after migrate (see bug 1207095).

Hi Martin,

would you please help to check the issue in step 4 in comment 11 ? Is this expect result as i see this in the doc:

"Thus, if you hit any bugs, you are on your own. Further details of that CPU can be changed using feature elements."

Thanks in advance for your reply.

Looks like John Ferlan was looking at the patch series posted for the bug mentioned.  I'm not sure where that ended since it was based on way older code base.  Good that there's a bug for the problem in step 5.

Looking at the step 4 only, it (of course) can't be true for host-passthrough since it is there to tell libvirt not to care what the CPU will look like, just to do what it wants.  The documentation says: "With this mode, the CPU visible to the guest should be exactly the same as the host CPU even in the aspects that libvirt does not understand." before saying you can modify it with <feature/> elements.  So I wouldn't necessarily say this is a problem.  We could change the behaviour by changing one line in the code, but there would be other problems.  This is something that, I think, cannot be handled before Bug 822148 if properly fixed.  You can mention this in that bug or create a new one that depends on it.

(In reply to Martin Kletzander from comment #13)
> Looks like John Ferlan was looking at the patch series posted for the bug
> mentioned.  I'm not sure where that ended since it was based on way older
> code base.  Good that there's a bug for the problem in step 5.
> 
> Looking at the step 4 only, it (of course) can't be true for
> host-passthrough since it is there to tell libvirt not to care what the CPU
> will look like, just to do what it wants.  The documentation says: "With
> this mode, the CPU visible to the guest should be exactly the same as the
> host CPU even in the aspects that libvirt does not understand." before
> saying you can modify it with <feature/> elements.  So I wouldn't
> necessarily say this is a problem.  We could change the behaviour by
> changing one line in the code, but there would be other problems.  This is
> something that, I think, cannot be handled before Bug 822148 if properly
> fixed.  You can mention this in that bug or create a new one that depends on
> it.

Okay, Verify this bug, and retest with libvirt-1.2.17-2.el7.x86_64 the step is the same with comment 11.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html