All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sheng Yang <sheng@linux.intel.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH][v2] Hybrid extension support in Xen
Date: Tue, 2 Feb 2010 23:51:42 +0800	[thread overview]
Message-ID: <201002022351.42696.sheng@linux.intel.com> (raw)
In-Reply-To: <C78DE912.8C3B%keir.fraser@eu.citrix.com>

On Tuesday 02 February 2010 22:37:06 Keir Fraser wrote:
> On 02/02/2010 14:32, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:
> >>> Okay, so that leads to the obvious next question: why do you want to
> >>> avoid using INIT-SIPI-SIPI?
> >>
> >> Because we don't have IOAPIC/LAPIC...
> >
> > Is it necessary to remove the LAPICs completely? If you go very far down
> > the route of ripping emulated stuff out of HVM, it starts to feel like
> > starting with a pure PV guest and HVMing it up is closer in spirit to
> > what you might be aiming for.
> 
> The other thing is, removing some of this stuff weakens the argument that
> the hybrid approach lets us 'ride the wave' of improving hardware virt
> support. For example, LAPIC is pretty architectural these days, and is ripe
> for fuller hardware virtualisation. If you put HVM onto event channels and
> totally rip out the LAPIC, where does that leave us if full LAPIC virt
>  comes along, with all its potential for especially improving device
>  passthru performance?

In fact, our target is improving device passthru performance(before full LAPIC 
virtualziation ready in every server). And what we mostly targeted is MSI/MSI-
X interrupt intensive devices. This didn't include in this patchset(we have 
experiment patches of course), because that can't avoid touching the some 
generic kernel code, e.g. MSI related things in ioapic.c, make it harder to be 
checked in. The code to support hybrid MSI/MSI-X device can be shared with 
pv_ops dom0, so that is what we planed next step.

And these hybrid features are component based. I admit, sooner or later, these 
PV solutions would be replaced with hardware features. If you got new enough 
hardwares, you can simply disable them; if you didn't, you can still benefit 
from them. Of course, as you know, it takes time to get new enough machine for 
everyone. So I think, it's better to do something now rather than simply 
waiting for hardware feature come. :)

-- 
regards
Yang, Sheng

  reply	other threads:[~2010-02-02 15:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-02  8:16 [PATCH][v2] Hybrid extension support in Xen Sheng Yang
2010-02-02 11:22 ` Ian Campbell
2010-02-02 12:54   ` Sheng Yang
2010-02-02 13:19     ` Ian Campbell
2010-02-02 13:28       ` Sheng Yang
2010-02-02 13:50         ` Ian Campbell
2010-02-02 14:00           ` Tim Deegan
2010-02-02 14:22             ` Sheng Yang
2010-02-02 14:28           ` Sheng Yang
2010-02-02 13:35   ` Keir Fraser
2010-02-02 13:52     ` Sheng Yang
2010-02-02 14:01       ` Keir Fraser
2010-02-02 14:13         ` Sheng Yang
2010-02-02 11:26 ` Ian Campbell
2010-02-02 13:06   ` Sheng Yang
2010-02-02 13:52     ` Ian Campbell
2010-02-02 14:04       ` Stefano Stabellini
2010-02-02 14:07       ` Sheng Yang
2010-02-02 16:15         ` Ian Campbell
2010-02-02 16:31           ` Sheng Yang
2010-02-02 18:03             ` Ian Campbell
2010-02-02 18:27             ` Stefano Stabellini
2010-02-03  5:15               ` Sheng Yang
2010-02-03 10:39                 ` Tim Deegan
2010-02-02 11:32 ` Paul Durrant
2010-02-02 13:23 ` Keir Fraser
2010-02-02 13:37   ` Sheng Yang
2010-02-02 14:03     ` Keir Fraser
2010-02-02 14:08       ` Sheng Yang
2010-02-02 14:32         ` Keir Fraser
2010-02-02 14:37           ` Keir Fraser
2010-02-02 15:51             ` Sheng Yang [this message]
2010-02-02 14:39           ` Sheng Yang
2010-02-02 13:52 ` Ian Campbell
2010-02-02 13:53   ` Sheng Yang

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=201002022351.42696.sheng@linux.intel.com \
    --to=sheng@linux.intel.com \
    --cc=eddie.dong@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=xen-devel@lists.xensource.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 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.