Re: [PATCH 0/1] x2apic implementation for kvm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 25, 2009 at 02:48:03PM +0800, Sheng Yang wrote:
> > > > > Yeah... x2apic is for interrupt remapping, and interrupt remapping is
> > > > > for VT-d engine. So if we don't want to virtualize VT-d engine and
> > > > > interrupt remapping, x2apic is useless for the guest... And VT-d
> > > > > engine(and related things) virtualization is far from our scope
> > > > > now...
> > > >
> > > > Can you explain why "x2apic is for interrupt remapping"? I can
> > > > understand why interrupt remapping is needed to use x2apic in certain
> > > > circumstances (apic ids > 256). x2apic has better virtualizable
> > > > interface and that is why we want to emulate it. Can you name one
> > > > technical reason why it can't be done in a context of KVM?
> > >
> > > As you know, x2apic is for apic id > 256. So, at least on the real
> > > machine, if there is no interrupt remapping, x2apic almost can't take
> > > much advantage, because IOAPIC and MSI/MSI-X delivery still using 8bit
> > > apic id, so any external interrupt can't benefit from it(though IPI can
> > > benefit some, and maybe some gain from MSR rather than MMIO). And this is
> > > the main purpose for x2apic, that's why Linux kernel limited x2apic using
> > > with interrupt remapping.
> > >
> > > I am not sure the things looks like in the context of KVM. I think mostly
> > > even you virtualize it, it can't replace lapic, for guest won't use it(I
> > > am not sure about the Windows). Can you explain more detail?
> >
> > KVM will expose x2apic, but will use apic ids < 256. Linux has to be
> > changed to use x2apic if it runs as a guest. Windows, when running as a
> > guest, partially paravirtualize lapic by using MSRs to access frequently
> > used registers. The MSR interface Windows uses is very similar to x2apic
> > by the way and KVM will support it too.
> >
> OK, you are totally talking about PV. For PV, I think let host kernel accept 
> the modification is more important here. (And for PV, using hypercall seems 
> more directly).
> 
I don't think hypercall will have performance advantage over MSR
intercept and using code that is already in kernel is better than
writing more code. Also Intel is better in defining interfaces that
we are ;)

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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux