This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [PATCH 0/7] PV on HVM: receive interrupts as xen events

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 0/7] PV on HVM: receive interrupts as xen events
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 3 Sep 2010 14:51:50 +0100
Cc: Konrad, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 03 Sep 2010 07:03:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C7FF538.7020704@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1008301134160.2545@kaball-desktop> <4C7FF538.7020704@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 2 Sep 2010, Jeremy Fitzhardinge wrote:
>  On 08/30/2010 04:20 AM, Stefano Stabellini wrote:
> > Hi all,
> > this patch series introduces some performance improvements for xen PV on
> > HVM guests: interacting with the emulated APIC is slow because it causes
> > traps in the hypervisor while receiving xen events using the vector callback
> > mechanism allow us to skip all that. For this reason we remap interrupts
> > and MSIs into xen pirqs so that from that point on we can receive them
> > as xen events instead.
> > This series is based on Konrad's pcifront series (not upstream yet):
> >
> > http://lkml.org/lkml/2010/8/4/374
> >
> > and requires a patch to xen and a patch to qemu-xen (just sent to
> > xen-devel).
> My only concern with this series is the pirq remapping stuff.  Why do
> pirq and irq need to be non-identical?  Is it because pirq is a global
> namespace, and dom0 has already assigned it?
> Why do guests need to know about max pirq?  Would it be better to make
> Xen use a more dynamic structure for pirqs so that any arbitrary value
> can be used?
No, pirq is a per-domain namespace, but pirq and irq are conceptually
different: pirqs are used by xen as a reference for interrupts of
devices assigned to the guest, while linux uses irqs for its
internal purposes.
The pirq namespace is chosen by xen while the linux irq namespace is
chosen by linux.
Linux is allowed to choose the pirq number it wants when mapping an
interrupt, this is why linux needs to know the max pirq, so that it can
safely chose a pirq that is in the allowed range.
The difference between pirqs and linux irqs increases when we talk about
PV on HVM guests: in this case qemu also maps interrupts in the guests
getting pirqs in return, so the linux kernel has to be able to cope with
already assigned pirq numbers.
The current PHYSDEVOP_map_pirq interface is already flexible enough for
that because it provides the possibility for the caller to let xen
choose the pirq, something that linux never does in the pure PV case,
but it is still possible. Obviously if you let xen choose the pirq
number you are safe from conflicts but you must be able to cope with
pirq numbers different from linux irq numbers.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>