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] Shared memory and event channel

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] Shared memory and event channel
From: Ritu kaur <ritu.kaur.us@xxxxxxxxx>
Date: Tue, 23 Feb 2010 07:53:28 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Daniel Stodden <Daniel.Stodden@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 23 Feb 2010 07:54:04 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=L630Sh1LeJviW612Cqb7KgL492KXcV2FoRt0bpPfEy8=; b=Ae2nWO9vAY1iQ3NjzGyN0Iqr9QyYxryT5Y5MMI2q5NppArlfDu9u71Mej5BnCUbGaN mvpsbv3Z9U1pKEQt0w807SvJP67hqFYgoBu46EnZc0Xzun0VrIeayFZbgSLkoPdNWX1c eH6OiSnhvIX3ydnqJbbEH5+n5Gf/N689cGZDs=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vuTo5lnmXIupKTs1gJtEk09N411WxWr5z5lhdl59kMsgxOXKCKhxiuYAoYi8+sRefn qD++Cu0lVYzDdn1RBPrkaYD2fZxsJ2OgML1yTFnT5tiZ7vMSyVmV7pi1274D1uZWNaq0 fG8ANdpBsDUxVCQu5VHYlqBoXMfS3CmOnYEgQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1266939735.11737.6397.camel@xxxxxxxxxxxxxxxxxxxxxx>
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: <29b32d341002211058l7e283336pa4fdfd0dc0b7124b@xxxxxxxxxxxxxx> <1266787199.24577.18.camel@xxxxxxxxxxxxxxxxxxxxxxx> <29b32d341002211533k4956a129ifff18281cfa92e41@xxxxxxxxxxxxxx> <1266825344.4996.183.camel@xxxxxxxxxxxxxxxxxxx> <29b32d341002220936q2f6f3cdaif3cbb766d1e644d1@xxxxxxxxxxxxxx> <1266874463.27288.57.camel@xxxxxxxxxxxxxxxxxxxxxxx> <29b32d341002221416t4e00b899q18e07a69ad24b07f@xxxxxxxxxxxxxx> <1266917906.11737.5928.camel@xxxxxxxxxxxxxxxxxxxxxx> <20100223144738.GC25741@xxxxxxxxxxxxxxxxxxx> <1266939735.11737.6397.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Ian,

Thanks for your inputs, I skimmed through Intel 82576 SR-IOV document and it looks like it needs hardware support and I don't think our hardware has it(will double check with our team). I believe currently there is no good solution other than using pci passthrough(with a single domU access). I just want to bring one thing and I hope it was not missed out from my earlier email i.e

"The NIC registers are memory mapped, can I take "machine memory address space(which is in dom0)" and remap it to domU's such that I can get multiple domU access. "

The above soln is just a thought, not sure it's feasible.

Thanks


On Tue, Feb 23, 2010 at 7:42 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
On Tue, 2010-02-23 at 14:47 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 23, 2010 at 09:38:26AM +0000, Ian Campbell wrote:
> > On Mon, 2010-02-22 at 22:16 +0000, Ritu kaur wrote:
> > >
> > > All I need to  is access NIC registers via domU's(network controller
> > > will still be working normally). Using PCI passthrough solves the
> > > problem for a domU, however, it doesn't solve when multiple domU's
> > > wanting to read NIC registers(ex. statistics).
> >
> > Direct access to hardware registers and availability of the device to
> > multiple guest domains are mutually exclusive configurations under Xen
> > (in the absence of additional technologies such as SR-IOV).
> >
> > The paravirtual front and back devices contain no hardware specific
> > functionality, in this configuration all hardware specific knowledge is
> > contained in the driver in domain 0. Guests use regular L2 or L3
> > mechanisms such as bridging, NAT or routing to obtain a path to the
> > physical hardware but they are never aware of that physical hardware.
> >
> > PCI passthrough allows a guest direct access to a PCI device but this is
> > obviously incompatible with access from multiple guests (again, unless
> > you have SR-IOV or something similar)
>
> What if the netback was set be able to work in guest mode? This way you
> could export it out to the guests?

Like a driver domain model? That would work (I think) but is still not
the same as having multiple domain's with access to the physical
registers. netback in a guest works in exactly the same as how it works
for domain 0.

Ian.


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