All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: Sheng Yang <sheng@linux.intel.com>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Keir Fraser <Keir.Fraser@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/7] xen: Make event channel work with PV featured HVM
Date: Tue, 9 Feb 2010 12:51:02 +0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1002091233110.11349@kaball-desktop> (raw)
In-Reply-To: <1265616354-7384-6-git-send-email-sheng@linux.intel.com>

On Mon, 8 Feb 2010, Sheng Yang wrote:
> We mapped each IOAPIC pin to a VIRQ, so that we can deliver interrupt through
> these VIRQs.
> 
> We used X86_PLATFORM_IPI_VECTOR as the noficiation vector for hypervisor
> to notify guest about the event.
> 
> The Xen PV timer is used to provide guest a reliable timer.
> 
> The patch also enabled SMP support, then we can support IPI through evtchn as well.
> 
> Then we don't need IOAPIC/LAPIC...
> 

First of all I want to say that this series looks much better than the
previous one.

However I think there might still be some room for improvement:
wouldn't it make more sense to map vectors to event channels instead of
IOAPIC pins? This way it could work for MSI and passthrought devices
too. Also it would make sense to have a per-vector delivery option in
vlapic.c in xen: vlapic_set_irq should probably be the function that
decides how to inject the vector into the guest, either using the
classic emulated method or an event channel.
The decision should come from a matrix so that the guest might decide to
enable event channels on a per vector basis instead of having a single
global switch.
It seems to me that doing an intx to event channel translation in
hvm/irq.c is not the right thing in the right place.



WARNING: multiple messages have this Message-ID (diff)
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: Sheng Yang <sheng@linux.intel.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Keir Fraser <Keir.Fraser@eu.citrix.com>
Subject: Re: [PATCH 5/7] xen: Make event channel work with PV featured HVM
Date: Tue, 9 Feb 2010 12:51:02 +0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1002091233110.11349@kaball-desktop> (raw)
In-Reply-To: <1265616354-7384-6-git-send-email-sheng@linux.intel.com>

On Mon, 8 Feb 2010, Sheng Yang wrote:
> We mapped each IOAPIC pin to a VIRQ, so that we can deliver interrupt through
> these VIRQs.
> 
> We used X86_PLATFORM_IPI_VECTOR as the noficiation vector for hypervisor
> to notify guest about the event.
> 
> The Xen PV timer is used to provide guest a reliable timer.
> 
> The patch also enabled SMP support, then we can support IPI through evtchn as well.
> 
> Then we don't need IOAPIC/LAPIC...
> 

First of all I want to say that this series looks much better than the
previous one.

However I think there might still be some room for improvement:
wouldn't it make more sense to map vectors to event channels instead of
IOAPIC pins? This way it could work for MSI and passthrought devices
too. Also it would make sense to have a per-vector delivery option in
vlapic.c in xen: vlapic_set_irq should probably be the function that
decides how to inject the vector into the guest, either using the
classic emulated method or an event channel.
The decision should come from a matrix so that the guest might decide to
enable event channels on a per vector basis instead of having a single
global switch.
It seems to me that doing an intx to event channel translation in
hvm/irq.c is not the right thing in the right place.

  parent reply	other threads:[~2010-02-09 13:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-08  8:05 [PATCH 0/7][v3] PV featured HVM(Hybrid) for Xen Sheng Yang
2010-02-08  8:05 ` [PATCH 1/7] xen: add support for hvm_op Sheng Yang
2010-02-08  8:05   ` Sheng Yang
2010-02-08  8:05 ` [PATCH 2/7] xen: Import cpuid.h from Xen Sheng Yang
2010-02-08  8:05 ` [PATCH 3/7] xen/hvm: Xen PV featured HVM initialization Sheng Yang
2010-02-08  8:05 ` [PATCH 4/7] xen: The entrance for PV featured HVM Sheng Yang
2010-02-08  8:05 ` [PATCH 5/7] xen: Make event channel work with " Sheng Yang
2010-02-09 11:52   ` Ian Campbell
2010-02-09 11:52     ` Ian Campbell
2010-02-09 12:46     ` Sheng Yang
2010-02-09 14:02       ` [Xen-devel] " Ian Campbell
2010-02-09 14:02         ` Ian Campbell
2010-02-09 17:17         ` [Xen-devel] " Sheng Yang
2010-02-09 17:17           ` Sheng Yang
2010-02-09 18:01           ` [Xen-devel] " Stefano Stabellini
2010-02-11  9:59             ` Sheng Yang
2010-02-12 11:59               ` [Xen-devel] Re: [PATCH 5/7] xen: Make event channel work with PV featured HVe Stefano Stabellini
2010-02-12 11:59                 ` Stefano Stabellini
2010-02-10  3:16         ` [Xen-devel] Re: [PATCH 5/7] xen: Make event channel work with PV featured HVM Nakajima, Jun
2010-02-10  3:16           ` Nakajima, Jun
2010-02-10 10:20           ` [Xen-devel] " Ian Campbell
2010-02-10 10:20             ` Ian Campbell
2010-02-11  9:59             ` [Xen-devel] " Sheng Yang
2010-02-09 12:51   ` Stefano Stabellini [this message]
2010-02-09 12:51     ` Stefano Stabellini
2010-02-08  8:05 ` [PATCH 6/7] xen: Unified checking for Xen of PV drivers to xenbus_register_frontend() Sheng Yang
2010-02-08  8:05 ` [PATCH 7/7] xen: Enable grant table and xenbus 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=alpine.DEB.2.00.1002091233110.11349@kaball-desktop \
    --to=stefano.stabellini@eu.citrix.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Jeremy.Fitzhardinge@citrix.com \
    --cc=Keir.Fraser@eu.citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sheng@linux.intel.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.