WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [rfc 00/18] ioemu: use devfn instead of slots as the uni

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Fri, 20 Feb 2009 18:07:00 +1100
Cc: Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Delivery-date: Thu, 19 Feb 2009 23:07:24 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5C2D910.2FFE%keir.fraser@xxxxxxxxxxxxx>
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: <20090219181707.0757.27C06F64@xxxxxxxxxxxxxxx> <C5C2D910.2FFE%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Feb 19, 2009 at 09:38:24AM +0000, Keir Fraser wrote:
> On 19/02/2009 09:21, "Yuji Shimada" <shimada-yxb@xxxxxxxxxxxxxxx> wrote:
> 
> >> To be honest I am a little confused about what the above maping
> >> is supposed to achive.
> > 
> > Please find the attached figure which shows the interrupt routing in
> > xen hypervisor.
> 
> The point being to deliberately permute the mapping to try to avoid
> accidental GSI sharing even if there are patterns in DEV:INTX usage (e.g.,
> all devs use INTA).

Thanks for the information, especially the diagram. It is very useful.

Armed with this new kowledge I have a few questions.

1. Shimada-san stated that shared GSI are not permitted for
   pass-through devices. Is it permitted for a GSI to be shared
   between a pass-through device and a non-pass-through device?
   The current scheme seems to leave scope for this as

   gsi 6 A = gsi 13 D = gsi 21 C = gsi 29 B
   gsi 7 A = gsi 14 D = gsi 22 C = gsi 30 B

2. In several places in ioemu:io/passthrough.c e_intx is set to 0,
   corresponding to INTA. Is this because it is virtual and
   using INTA is convenient? Or is it because it is assumed
   that the physical device being passed-through is a 0 function
   (and 0 functions always use INTA) ?

   The latter assumption is not valid because even without my pacthes
   it is possible to pass-through non-0 functions, its just that
   they end up as the 0th function of the virtual slot in the guest.


I am now pretty sure that my change leads to incorrect usage of
hvm_pci_intx_gsi(). Answers to the questions above will help me to
understand how trivial to fix this is.

The most difficult cases seem to be 1) sharing of gsi between
pass-through and non-pass-through devices is not permitted or 2)
intx used inside ioemu:io/passthrough.c should reflect the physical
intx. In either case I wonder if a reasonable solution would be to
just allocate allocate GSI in a non-colliding manner. Say, GSI 16 for
the first device to ask, 17 for the next one and so on. Or perhaps
the existing hash + overflow to the next GSI on collision.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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