From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ritu kaur Subject: Re: Shared memory and event channel Date: Tue, 23 Feb 2010 07:53:28 -0800 Message-ID: <29b32d341002230753r2a1a028dpf276f68b0cca48a@mail.gmail.com> References: <29b32d341002211058l7e283336pa4fdfd0dc0b7124b@mail.gmail.com> <1266787199.24577.18.camel@agari.van.xensource.com> <29b32d341002211533k4956a129ifff18281cfa92e41@mail.gmail.com> <1266825344.4996.183.camel@ramone.somacoma.net> <29b32d341002220936q2f6f3cdaif3cbb766d1e644d1@mail.gmail.com> <1266874463.27288.57.camel@agari.van.xensource.com> <29b32d341002221416t4e00b899q18e07a69ad24b07f@mail.gmail.com> <1266917906.11737.5928.camel@zakaz.uk.xensource.com> <20100223144738.GC25741@phenom.dumpdata.com> <1266939735.11737.6397.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0007784568==" Return-path: In-Reply-To: <1266939735.11737.6397.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Daniel Stodden , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org --===============0007784568== Content-Type: multipart/alternative; boundary=000e0cd1145c03e45f0480468d7e --000e0cd1145c03e45f0480468d7e Content-Type: text/plain; charset=ISO-8859-1 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 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. > > --000e0cd1145c03e45f0480468d7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 ac= cess). 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 i= t to domU's such that I can get multiple domU access. "

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

Th= anks


On Tue, Feb 23, 2010 at 7:42 AM,= Ian Campbell <Ian.Campbell@citrix.com> wrote:
<= div class=3D"h5">On Tue, 2010-02-23 at 14:47 +0000, Konrad Rzeszutek Wilk w= rote:
> 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 =A0is access NIC registers via domU's(netw= ork controller
> > > will still be working normally). Using PCI passthrough solve= s the
> > > problem for a domU, however, it doesn't solve when multi= ple domU's
> > > wanting to read NIC registers(ex. statistics).
> >
> > Direct access to hardware registers and availability of the devic= e to
> > multiple guest domains are mutually exclusive configurations unde= r Xen
> > (in the absence of additional technologies such as SR-IOV).
> >
> > The paravirtual front and back devices contain no hardware specif= ic
> > functionality, in this configuration all hardware specific knowle= dge is
> > contained in the driver in domain 0. Guests use regular L2 or L3<= br> > > mechanisms such as bridging, NAT or routing to obtain a path to t= he
> > physical hardware but they are never aware of that physical hardw= are.
> >
> > PCI passthrough allows a guest direct access to a PCI device but = this is
> > obviously incompatible with access from multiple guests (again, u= nless
> > you have SR-IOV or something similar)
>
> What if the netback was set be able to work in guest mode? This way yo= u
> could export it out to the guests?

Like a driver domain model? That would work (I think) but is st= ill 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.


--000e0cd1145c03e45f0480468d7e-- --===============0007784568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0007784568==--