All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritu kaur <ritu.kaur.us@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Daniel Stodden <Daniel.Stodden@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: Shared memory and event channel
Date: Tue, 23 Feb 2010 07:53:28 -0800	[thread overview]
Message-ID: <29b32d341002230753r2a1a028dpf276f68b0cca48a@mail.gmail.com> (raw)
In-Reply-To: <1266939735.11737.6397.camel@zakaz.uk.xensource.com>


[-- Attachment #1.1: Type: text/plain, Size: 2361 bytes --]

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@citrix.com>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.
>
>

[-- Attachment #1.2: Type: text/html, Size: 3033 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

  reply	other threads:[~2010-02-23 15:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <29b32d341002211058l7e283336pa4fdfd0dc0b7124b@mail.gmail.com>
     [not found] ` <1266787199.24577.18.camel@agari.van.xensource.com>
2010-02-21 23:33   ` Shared memory and event channel Ritu kaur
2010-02-22  7:55     ` Daniel Stodden
2010-02-22 17:36       ` Ritu kaur
2010-02-22 21:34         ` Daniel Stodden
2010-02-22 22:16           ` Ritu kaur
2010-02-23  9:38             ` Ian Campbell
2010-02-23 14:47               ` Konrad Rzeszutek Wilk
2010-02-23 15:42                 ` Ian Campbell
2010-02-23 15:53                   ` Ritu kaur [this message]
2010-02-23 17:42                     ` djmagee
2010-02-23 19:26                       ` Ritu kaur
2010-02-24  9:38                         ` Ian Campbell
2007-11-19  7:59 shared " Amit Singh
2007-11-28  1:45 ` Mark Williamson
2007-12-21  8:39   ` tgh
2007-12-21 12:54     ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29b32d341002230753r2a1a028dpf276f68b0cca48a@mail.gmail.com \
    --to=ritu.kaur.us@gmail.com \
    --cc=Daniel.Stodden@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.