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: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Subject: Re: [Xen-devel] [rfc 00/18] ioemu: use devfn instead of slots as the unit for passthrough
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Thu, 5 Mar 2009 21:13:01 +1100
Cc: Yuji Shimada <shimada-yxb@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 05 Mar 2009 02:13:26 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090305095720.GA18949@xxxxxxxxxxxx>
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: <20090305090507.GB12961@xxxxxxxxxxxx> <C5D54B3A.4354%keir.fraser@xxxxxxxxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C7CE8E41@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090305095720.GA18949@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Mar 05, 2009 at 08:57:20PM +1100, Simon Horman wrote:
> On Thu, Mar 05, 2009 at 05:31:15PM +0800, Jiang, Yunhong wrote:
> > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <> wrote:
> > > On 05/03/2009 09:05, "Simon Horman" <horms@xxxxxxxxxxxx> wrote:
> > > 
> > >> * I have not accounted for MSI devices/functions at this time,
> > >>   but my understanding is that they don't need a GSI at all.
> > >>   So it should be just a matter of giving them a device
> > >>   and making sure nothing else uses it.
> > > 
> > > Depending on how critical your
> > > no-sharing-between-passthru-devices is, you
> > > might need to be careful with this. Just because a device is MSI-capable
> > > doesn't mean the guest OS will use it (I don't know how common
> > > that would be
> > 
> > I think most OS will support a option to disable MSI, like Vista or Linux.
> 
> So it is entirely possible that MSI won't be used on an MSI-capable
> function?  Is this true of SR-IOV (virtual) functions too?

Thinking more. One of the arguments surounding why 32 GSI is enough,
is that systems with more functions than that can reasonably be
expected to be using MSI. And thus will not actually use more than 32 GSI.

I agree with that argument. But in terms of reserving GSI, it seems to
break down if we can never know if a function will actually use MSI, and
thus need to reserve a GSI just in case.

Perhaps this is a case of find a real-world example and then
we will worry about it?

Or perhaps hints are required from xend and in turn the user - its ok, MSI
will be used for this function, so there is no need to reserve a GSI for it.

-- 
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>