Bug 768450

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

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.

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?

(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?

I believe kvm64 and qemu64 are not supported by Red Hat and should not be exposed. cpu64-rhel* should.

(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.

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.

(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?

> Maybe Saveliev Peter is jsut asking support for the cpu64-rhel* CPU models?

Correct.

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

Back to ON_QA, patch is in libvirt-0.9.10-5.el6,

Daniel

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.

    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

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