Sheng Yang wrote:
On Monday 25 May 2009 17:22:34 Avi Kivity wrote:
Sheng Yang wrote:
I think that means the PV interface for lapic. And yes, we can support it
follow MS's interface, but x2apic still seems another story as you
noted... I still don't think support x2apic here would bring us more
benefits.
x2apic has the following benefit:
- msr exits are faster than mmio (no page table walk, emulation)
Need PV(at least part of). I don't think Hyper-V considered this, and not sure
the community's aptitude.
Hyper-V does define MSRs for local apic access, as far as I can tell
they're identical to x2apic except for the msr index.
- potential to support large guests once we add interrupt remapping
Then it can be added before we have it. Compared to the workload, x2apic is
not the problem, interrupt remapping/VT-d is.
I'd like to have the benefit sooner. x2apic provides two user-visible
benefits: performance and large guests. I don't want performance to
wait for large guests.
- shared code with the Hyper-V paravirt interface
So I think the key thing are ICR related(and seems no data available
currently). Compare the benefit of ICR improve(can it improved in another way?
Does Hyper-V interface has related things?), and the workload of x2apic
virtualization as well as guest OS support, well, I don't know, but not
optimistic
x2apic, without interrupt remapping, is fairly simple.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
