Bug 768450 - libvirt should have mapping for cpu64-rhel cputype
Summary: libvirt should have mapping for cpu64-rhel cputype
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Martin Kletzander
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-16 17:17 UTC by Saveliev Peter
Modified: 2013-11-01 00:59 UTC (History)
11 users (show)

(edit)
Cause
    There were no mappings specified for cpu64-rhel* CPU models found in qemu
Consequence
    cpu64-rhel* cpu models were not used
Change
    Mappings for cpu64-rhel* CPU models were added
Result
    cpu64-rhel* CPU models from RHEL qemu can now be used
Clone Of:
(edit)
Last Closed: 2012-06-20 06:39:13 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0748 normal SHIPPED_LIVE Low: libvirt security, bug fix, and enhancement update 2012-06-19 19:31:38 UTC

Description Saveliev Peter 2011-12-16 17:17:55 UTC
libvirt should list qemu64-cpu as a supported guest CPU type.

Comment 2 Dave Allan 2011-12-16 17:44:26 UTC
Hi Peter (Saveliev that is, since I've assigned the BZ to Peter Krempa for the moment),

I'm trying to set priorities on the 6.3 BZs.  What's driving this RFE?

Dave

Comment 3 Dan Kenigsberg 2011-12-22 18:14:53 UTC
My intention is mainly internal testing of a "maximal" cpu type, with no strings attached to emulating real cpu. I believe that qemu-kvm decided to expose -- and support -- this cpu type for a reason (am I right, Dor?). Blocking a qemu-supported cpu type in the libvirt level does not make much sense imo.

Comment 4 Martin Kletzander 2012-01-18 13:27:21 UTC
So IIUC, this CPU type would be basically enable all the flags supported by the qemu binary, not based on anything else. Just full support for everything, am I right?

Comment 6 Dan Kenigsberg 2012-01-26 13:05:39 UTC
(In reply to comment #4)
> So IIUC, this CPU type would be basically enable all the flags supported by the
> qemu binary, not based on anything else. Just full support for everything, am I
> right?

I think this is much more limited than that - it is the set of qemu64 features that are supported by Red Hat at the qemu-kvm level. I am not sure which are theses features exactly, and would rather relay this qemu-related question to a qemu guy. Luiz?

Comment 8 Dan Kenigsberg 2012-01-30 11:37:21 UTC
I believe kvm64 and qemu64 are not supported by Red Hat and should not be exposed. cpu64-rhel* should.

Comment 9 Luiz Capitulino 2012-01-30 11:51:05 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > So IIUC, this CPU type would be basically enable all the flags supported by the
> > qemu binary, not based on anything else. Just full support for everything, am I
> > right?
> 
> I think this is much more limited than that - it is the set of qemu64 features
> that are supported by Red Hat at the qemu-kvm level. I am not sure which are
> theses features exactly, and would rather relay this qemu-related question to a
> qemu guy. Luiz?

Eduardo is working with CPU flags in qemu, I think he's in a better position to answer you here.

Comment 10 Martin Kletzander 2012-01-30 15:46:01 UTC
This bug is actually just about cpu model support for cpu64-rhel5 and cpu64-rhel6. The patch was send and is now waiting to be pushed, so no other information is needed anymore. I'll update this bug when the patch is pushed.

Comment 11 Eduardo Habkost 2012-02-01 17:17:57 UTC
(In reply to comment #9)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > So IIUC, this CPU type would be basically enable all the flags supported by the
> > > qemu binary, not based on anything else. Just full support for everything, am I
> > > right?
> > 
> > I think this is much more limited than that - it is the set of qemu64 features
> > that are supported by Red Hat at the qemu-kvm level. I am not sure which are
> > theses features exactly, and would rather relay this qemu-related question to a
> > qemu guy. Luiz?
> 
> Eduardo is working with CPU flags in qemu, I think he's in a better position to
> answer you here.

I can't answer that question as it's a question about "what's being requested here?" instead of "what qemu supports". Anyway, if you want to know what's included on each mode, use the "-cpu ?dump" qemu-kvm command-line option.

In case that's what being requested: I don't think a CPU definition meaning "everything supported by qemu-kvm" exists on Qemu. We have "-cpu host" but it's not something we support, because it may include too much, including features that require qemu-kvm support to work. qemu64 and cpu64-rhel* are closer to a "minimal" CPU type than a "maximal" CPU type.

In theory, libvirt can implement such "maximal" CPU type by querying the supported flags using "-cpu ?cpuid" and building an appropriate "-cpu" argument.

But I have no idea what exactly is being requested here. Maybe Saveliev Peter is jsut asking support for the cpu64-rhel* CPU models?

Comment 12 Dan Kenigsberg 2012-02-01 20:57:16 UTC
> Maybe Saveliev Peter is jsut asking support for the cpu64-rhel* CPU models?

Correct.

Comment 16 min zhan 2012-03-07 08:24:34 UTC
Reproduced this bug with libvirt-0.9.4-23.el6.

Tested this bug with libvirt-0.9.10-4.el6:

1. Check cpu_map.xml, found the cpu64-rhel5/6 are added.

# cat /usr/share/libvirt/cpu_map.xml |grep cpu64-rhel
    <model name='cpu64-rhel5'>
    <model name='cpu64-rhel6'>

2. Check guest could be started with cpu64-rhel6 model or not.

1) Tested with *Intel* machine, i find some issues here. And same results as cpu64-rhel5 model. I think this bug is not totally fixed. So I assign this bug back.

# virsh dumpxml guest
...
 <cpu mode='custom' match='exact'>
    <model fallback='allow'>cpu64-rhel6</model>
  </cpu>
...

# virsh start rhel62-clone
error: Failed to start domain rhel62-clone
error: internal error guest CPU is not compatible with host CPU


2) But Tested with *AMD* machine, it works well:

# virsh dumpxml guest
...
 <cpu mode='custom' match='exact'>
    <model fallback='allow'>cpu64-rhel6</model>
  </cpu>
...

# virsh start guest
Domain rhel6.2 started

# ps -ef|grep kvm
qemu     27689     1 41 02:29 ?        00:00:44 /usr/libexec/qemu-kvm -S -M rhel6.3.0 -cpu cpu64-rhel6 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6.2 -uuid 4a3f08e4-77d3-94f2-acd4-009d254a35f8 -nodefconfig -nodefaults .....

Also Check in guest, # cat /proc/cpuinfo found the cpu model is 
model name: QEMU Virtual CPU version (cpu64-rhel6)

3) Other issue about fallback attribute during testing: 
I find whenever fallback is allow or forbid, guest could be started successfully with the qemu cmd having no difference between them, which is '-cpu cpu64-rhel6' always. Maybe there is a bug for it, i guess. 

Could you help to confirm? Thanks

Comment 20 Daniel Veillard 2012-03-13 10:11:28 UTC
Back to ON_QA, patch is in libvirt-0.9.10-5.el6,

Daniel

Comment 21 min zhan 2012-03-14 06:27:10 UTC
Re-test with libvirt-0.9.10-5.el6, steps are the same as Comment 16.

1) Tested with *Intel* machine

# virsh dumpxml guest
...
 <cpu mode='custom' match='exact'>
    <model fallback='allow'>cpu64-rhel6</model>
  </cpu>
...

# virsh start guest
Domain rhel62 started
# ps -ef|grep kvm
qemu      6006     1  6 23:09 ?        00:00:23 /usr/libexec/qemu-kvm -S -M rhel6.2.0 -cpu cpu64-rhel6 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel62 ....

Also Check in guest, # cat /proc/cpuinfo found the cpu model is 
model name: QEMU Virtual CPU version (cpu64-rhel6)

2) The results are the same for ADM machine and for cpu64-rhel5 type.

So move it to Verified.

Comment 22 Martin Kletzander 2012-05-03 13:07:31 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    There were no mappings specified for cpu64-rhel* CPU models found in qemu
Consequence
    cpu64-rhel* cpu models were not used
Change
    Mappings for cpu64-rhel* CPU models were added
Result
    cpu64-rhel* CPU models from RHEL qemu can now be used

Comment 24 errata-xmlrpc 2012-06-20 06:39:13 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.

http://rhn.redhat.com/errata/RHSA-2012-0748.html


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