All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sheng Yang <sheng@linux.intel.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 0/1] x2apic implementation for kvm
Date: Mon, 25 May 2009 14:48:03 +0800	[thread overview]
Message-ID: <200905251448.04183.sheng@linux.intel.com> (raw)
In-Reply-To: <20090525063811.GC3948@redhat.com>

On Monday 25 May 2009 14:38:11 Gleb Natapov wrote:
> On Mon, May 25, 2009 at 02:30:05PM +0800, Sheng Yang wrote:
> > On Monday 25 May 2009 14:13:23 Gleb Natapov wrote:
> > > On Mon, May 25, 2009 at 02:08:26PM +0800, Sheng Yang wrote:
> > > > On Friday 22 May 2009 01:37:53 Gleb Natapov wrote:
> > > > > This is implementation of x2apic for KVM that I wrote a while ago.
> > > > > Unfortunately there is no guest that can take advantage of it since
> > > > > Linux doesn't (yet?) use x2apic if interrupt remapping is not
> > > > > enabled and I don't feel like implement interrupt remapping device
> > > > > :)
> > > > >
> > > > > Re-based to latest kvm tree for your viewing pleasure and feedback.
> > > >
> > > > 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).

-- 
regards
Yang, Sheng

  reply	other threads:[~2009-05-25  6:46 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 [this message]
2009-05-25  6:57           ` Gleb Natapov
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=200905251448.04183.sheng@linux.intel.com \
    --to=sheng@linux.intel.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.