public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Sheng Yang <sheng@linux.intel.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 0/1] x2apic implementation for kvm
Date: Mon, 25 May 2009 09:57:25 +0300	[thread overview]
Message-ID: <20090525065725.GD3948@redhat.com> (raw)
In-Reply-To: <200905251448.04183.sheng@linux.intel.com>

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.

  reply	other threads:[~2009-05-25  6:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-21 17:37 [PATCH 0/1] x2apic implementation for kvm Gleb Natapov
2009-05-21 17:37 ` [PATCH 1/1] x2apic interface to lapic Gleb Natapov
2009-05-31 12:44   ` Avi Kivity
2009-05-21 17:37 ` [PATCH 2/2] Advertise X2APIC support Gleb Natapov
2009-05-24  6:46   ` Dor Laor
2009-05-24  6:48     ` Gleb Natapov
2009-06-08 12:13   ` Avi Kivity
2009-05-25  6:08 ` [PATCH 0/1] x2apic implementation for kvm Sheng Yang
2009-05-25  6:13   ` Gleb Natapov
2009-05-25  6:30     ` Sheng Yang
2009-05-25  6:38       ` Gleb Natapov
2009-05-25  6:48         ` Sheng Yang
2009-05-25  6:57           ` Gleb Natapov [this message]
2009-05-25  9:07           ` Avi Kivity
2009-05-25  9:19             ` Sheng Yang
2009-05-25  9:22               ` Avi Kivity
2009-05-25  9:40                 ` Dong, Eddie
2009-05-25  9:50                   ` Avi Kivity
2009-05-25  9:59                 ` Sheng Yang
2009-05-25 10:49                   ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090525065725.GD3948@redhat.com \
    --to=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=sheng@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox