Bug 1178850 - host-passthrough should allow enabling/disabling CPU flags
Summary: host-passthrough should allow enabling/disabling CPU flags
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Martin Kletzander
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1175463
TreeView+ depends on / blocked
 
Reported: 2015-01-05 14:43 UTC by Luiz Capitulino
Modified: 2015-11-19 06:06 UTC (History)
10 users (show)

Fixed In Version: libvirt-1.2.13-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 06:06:11 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description Luiz Capitulino 2015-01-05 14:43:32 UTC
Description of problem:

The cpu mode "host-passthrough" doesn't accept the enabling/disabling of CPU flags. 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:

-cpu host +tsc-deadline,pmu=off

However, it's impossible to do this with current libvirt.

Version-Release number of selected component (if applicable): libvirt-1.2.8-11.el7.x86_64

Comment 1 Martin Kletzander 2015-01-05 14:59:52 UTC
Is it safe if we allow enabling/disabling of all flags for all qemu versions or are there some restrictions?

Comment 2 Luiz Capitulino 2015-01-05 17:06:20 UTC
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.

Comment 3 Martin Kletzander 2015-01-05 20:42:33 UTC
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).

Comment 4 Luiz Capitulino 2015-01-05 20:51:50 UTC
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?

Comment 5 Eduardo Habkost 2015-01-06 13:20:27 UTC
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).

Comment 6 Eduardo Habkost 2015-01-06 13:30:09 UTC
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.

Comment 7 Luiz Capitulino 2015-01-06 17:57:20 UTC
Using -cpu host was the easiest and simplest way to get started with real-time measurements. We may move away from it soon.

Comment 8 Martin Kletzander 2015-01-07 13:47:40 UTC
That's what <cpu mode='host-model'/> is for (and it already accepts modifying cpu flags).

Comment 9 Martin Kletzander 2015-01-13 07:58:08 UTC
Fixed upstream with v1.2.11-143-gadff345:

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

    qemu: Allow enabling/disabling features with host-passthrough

Comment 11 Luyao Huang 2015-06-16 03:34:17 UTC
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).

Comment 12 Luyao Huang 2015-06-16 03:41:55 UTC
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.

Comment 13 Martin Kletzander 2015-06-16 13:48:13 UTC
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.

Comment 14 Luyao Huang 2015-07-30 03:33:51 UTC
(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.

Comment 16 errata-xmlrpc 2015-11-19 06:06:11 UTC
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


Note You need to log in before you can comment on or make changes to this bug.