Depending on the design there will be more or less libvirt impact, possibly none.  Jiri, please talk to Eduardo about the design and see what you think.

So far the direction seems to be that qemu-kvm will implement CPU models that will differ according to the machine type used. This will be completely transparent to libvirt. Libvirt will think SandyBridge model will always contain TSC-deadline feature.

(In reply to comment #6)
> So far the direction seems to be that qemu-kvm will implement CPU models
> that will differ according to the machine type used. This will be completely
> transparent to libvirt. Libvirt will think SandyBridge model will always
> contain TSC-deadline feature.

Yes, that's the plan: to implement in the in qemu-kvm in a way that doesn't affect libvirt (or affect it only in minor ways, like in the case of TSC-deadline).

I think this can be closed as NOTABUG, as long as there's a TSC-deadline-specific bug already open for libvirt.

OK, bug 804749 tracks the addition of TSC-deadline to SandyBridge model; I'm closing this bug. BTW, Eduardo, could you update the qemu-kvm bug 833152 with the current plan?

The right solution is still not finalized upstream but there's a possibility some changes will be needed in the way libvirt probes for available CPU models. I'll keep this bug open as a reminder...

The solution for qemu has been agreed on upstream and no work needs to be done on libvirt. I'm marking this bug as TestOnly. Before testing it, please, wait until bug 833152 is done.

Verify it as follows.The result is expected. So move its status to VERIFIED.

Steps
1. Prepare two host as follows.

# uname -r
2.6.32-338.el6.x86_64

# rpm -q libvirt qemu-kvm
libvirt-0.10.2-9.el6.x86_64
qemu-kvm-0.12.1.2-2.334.el6.x86_64

2. Start one rhel 6.4 guest on rhel 6.4 host.

# virsh start rhel64 
Domain rhel64 started

# ps -ef|grep rhel64
qemu     21063     1 39 16:13 ?        00:00:16 /usr/libexec/qemu-kvm -name rhel64 -S -M rhel6.4.0 -cpu SandyBridge,

3. Check tsc_deadline_timer flags in guest 
# cat /proc/cpuinfo|grep tsc_deadline_timer
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm xsaveopt


4.Start one rhel6.3 guest on rhel6,4 host 

# virsh start rhel63
Domain rhel63 started

# ps -ef|grep rhel63
qemu     22066     1 43 16:26 ?        00:00:04 /usr/libexec/qemu-kvm -name rhel63 -S -M rhel6.3.0 -cpu SandyBridge


5. Check tsc_deadline_timer flag in guest, no tsc_deadline_timer
# cat /proc/cpuinfo|grep tsc_deadline_timer

Add migration test.

Ping-Pong migrating rhel6.3 guest (-cpu SandyBridge) between RHEL6.4 and RHEL6.3 host (Both hosts are SandyBridge)

Steps

From host A to host B
# virsh migrate rhel6.3 --live qemu+ssh://host B ip/system

Check tsc_deadline_timer flag in guest, no tsc_deadline_timer
# cat /proc/cpuinfo|grep tsc_deadline_timer

From host B to host A
# virsh migrate rhel6.3 --live qemu+ssh://host A ip/system

Check tsc_deadline_timer flag in guest, no tsc_deadline_timer
# cat /proc/cpuinfo|grep tsc_deadline_timer


Result:
The guset rhel6.3 doesn't have tsc_deadline_timer flag on both hosts.


Ping-Pong migrating rhel6.4 guest (-cpu SandyBridge) guest between RHEL6.4 and RHEL6.4 host (Both hosts are SandyBridge)

Result:
The guset rhel6.4 always has tsc_deadline_timer flag on both hosts.

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-2013-0276.html