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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1009031240510.2714@kaball-desktop>
Date:	Fri, 3 Sep 2010 14:51:50 +0100
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH 0/7] PV on HVM: receive interrupts as xen events

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/