Re: [libvirt] [Qemu-devel] [Question] why x2apic's set by default without host support(on Nehalem CPU).
8:41 a.m.
On Mon, Jul 22, 2013 at 07:24:24PM +0800, Peter Huang(Peng) wrote:
Hi, Everyone
I have been encountered a problem recently.
My box uses Nehalem E5520 CPU, and this model doesn't support x2apic feature.
I created a VM on KVM, and uses cpu mode=pass-through, I can get the right cpu
model from the VM, but I can also see that the CPU in the vm supports x2apic.
This seems werid.
From QEMU's CPU model definition, Nehalem also doesn't support x2apic.
Can anyone explain it?
libvirt's "host-passthrough" uses "-cpu host', and it "-cpu
host"
enables every feature that can be enabled on the host. As KVM x2apic
emulation doesn't require host CPU support, it gets enabled.
If the behavior of "-cpu host" doesn't match libvirt expectations, we
need to clarify what are the requirements, and maybe have a "try to be
close to host CPU mode" as opposed to the current "enable everything
that can be enabled" mode.
--
Eduardo
9:44 p.m.
New subject: [libvirt] [Qemu-devel] [Question] why x2apic's set by default without host support(on Nehalem CPU).
libvirt's "host-passthrough" uses "-cpu host',
and it "-cpu host"
enables every feature that can be enabled on the host.
From my test results, I found that even when use host-passthrough mode, VM's
cpu
features are very different from host, this doesn't match what host-passthrough
mode's explanation.
libvirt's option exlanation:
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.
If the behavior of "-cpu host" doesn't match libvirt
expectations, we
need to clarify what are the requirements, and maybe have a "try to be
close to host CPU mode" as opposed to the current "enable everything
that can be enabled" mode.
Does the results above indicates what you mean to
do? or the current way doesn't work
as we expect.
Thanks!
6:27 a.m.
New subject: [libvirt] [Qemu-devel] [Question] why x2apic's set by default without host support(on Nehalem CPU).
On Tue, Jul 23, 2013 at 10:44:48 +0800, Peter Huang(Peng) wrote:
> libvirt's "host-passthrough" uses "-cpu
host', and it "-cpu host"
> enables every feature that can be enabled on the host.
From my test results, I found that even when use host-passthrough mode, VM's
cpu features are very different from host, this doesn't match what host-passthrough
mode's explanation.
libvirt's option exlanation:
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.
The libvirt documentation is what needs to be updated. While
host-passthrough is asking for a CPU which is as close as possible to
the real host CPU, there are features that need special handling before
they can be provided to a guest. And if the hypervisor does not provide
that handling, it may just filter such feature out. Also if some
features can be efficiently provided to a guest even though the host CPU
does not provide them (x2apic is an example of such feature), they may
be provided to a guest.
Jirka
7:48 p.m.
New subject: [libvirt] [Qemu-devel] [Question] why x2apic's set by default without host support(on Nehalem CPU).
Hi,Jiri
Thanks for replying.
So why VM identified different features from host is due to the hypervisor filtering.
I will dig into the hypervisor of how it filter features, and update status later.
Thanks again.
On 2013-07-23 19:27, Jiri Denemark wrote:
On Tue, Jul 23, 2013 at 10:44:48 +0800, Peter Huang(Peng) wrote:
>> libvirt's "host-passthrough" uses "-cpu host', and it
"-cpu host"
>> enables every feature that can be enabled on the host.
> From my test results, I found that even when use host-passthrough mode, VM's
> cpu features are very different from host, this doesn't match what
host-passthrough
> mode's explanation.
>
> libvirt's option exlanation:
> 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.
The libvirt documentation is what needs to be updated. While
host-passthrough is asking for a CPU which is as close as possible to
the real host CPU, there are features that need special handling before
they can be provided to a guest. And if the hypervisor does not provide
that handling, it may just filter such feature out. Also if some
features can be efficiently provided to a guest even though the host CPU
does not provide them (x2apic is an example of such feature), they may
be provided to a guest.
Jirka
9:54 p.m.
New subject: [libvirt] [Solved]FYI//Re: [Qemu-devel] [Question] why x2apic's set by default without host support(on Nehalem CPU).
FYI, just for information sharing.
KVM emulated x2apic feature no matter host supports it or not.
You can get the code from arch/x86/kvm/cpuid.c.
kvm_dev_ioctl_get_supported_cpuid ()->do_cpuid_ent()
/* we support x2apic emulation even if host does not support
* it since we emulate x2apic in software */
entry->ecx |= F(*X2APIC*);
QEMU will get this feature through kvm_ioctl().
On 2013-07-24 8:48, Peter Huang(Peng) wrote:
Hi,Jiri
Thanks for replying.
So why VM identified different features from host is due to the hypervisor filtering.
I will dig into the hypervisor of how it filter features, and update status later.
Thanks again.
4139
days inactive
4141
days old
4 comments
3 participants
participants (3)
-
Eduardo Habkost -
Jiri Denemark -
Peter Huang(Peng)