Re: Shared memory and event channel

[Ritu kaur <ritu.kaur.us@gmail.com>]

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

Hi Daniel,

Thanks once again and reply/question's inline...

On Sun, Feb 21, 2010 at 11:55 PM, Daniel Stodden
<daniel.stodden@citrix.com>wrote:

> On Sun, 2010-02-21 at 18:33 -0500, Ritu kaur wrote:
> > Hi Daniel,
> >
> > Thanks for the explanation, however, my main question is still
> > unanswered
> >
> > "My understanding is one has to use xenbus(registering and monitoring
> > for device creation) mechanism to setup shared mem rings and event
> > channel between dom's and there is no other way to do it."
>
> Anything capable of passing two integers around could give you a shared
> memory connection.
>

I want to know more about "anything capable". I have read documents from
xen.org and so far my understanding is that the only mechanism of setting up
shared mem rings is via xenbus(since PV drivers are the only users
currently),  pointers or example code which uses alternate mechanism will be
helpful.


> > All I need is to setup NIC register reads and writes from domUs(ioctl
> > is one such application which I have been discussing in another
> > thread) and to implement this I considered an option of using shared
> > memory rings. If answer to the above question is "Yes" then probably I
> > will not take that route.
>
> You need to understand that netback and the interface corresponding to
> your hardware NIC have no direct association. Netback just provides a
> kernel network interface, not the hardware controller. As any good
> network citizen, it passes packet buffers around, without any
> assumptions were they go. Not even an implicit assumption that somewhere
> in there is a physical NIC involved at all.
>
> There's a galaxy of layer 2/3 stuff between netback and the hardware.
> Bridging, routing, NAT etc., all in different variants. For XCP it's
> typically bridged. Netback won't know, because it doesn't have to.
>
> And least of all it wants to learn about your NIC.
>
> > It will be really helpful if you can elaborate on "why not just write
> > an auxiliary driver adding only added functionality but remaining
> > separate from the base networking stack"
>
> You would not even have to take down the vifs to prevent domU access to
> a NIC. The aren't bound to the NIC anyway.
>
> For low-level access to the NIC, you also don't necessarily need to set
> up message passing. Even if you would, none of that belongs into the PV
> interface.
>
> I'm not sure right now how easy the control plane in XCP will make it
> without other domU's notice, but maybe consider something like:
>
>  1. Take the physical NIC out of the virtual network.
>  2. Take the driver down.
>  3. Pass access to the NIC to a domU.
>  4. Let domU do the unspeakable.
>  5.-7. Revert 3,2,1 to normal.
>
> This won't mess with the the PV drivers. Get PCI passthrough to work for
> 3 and 4 and you save yourself a tedious ring protocol design. If not,
> consider doing the hardware programming in dom0, because there's not
> much left for domU anyway.
>
> You need a split toolstack to get the dom0 network control steps on
> behalf of domU done. Might be just a scripted agent, accessible to domU
> via a couple RPCs. Could also turn out to be as simple as talking
> through the primary vif, because the connection between domU and dom0
> could remain unaffected.
>
>
PCI passthrough is via config changes and no code changes, if that's the
case I am not sure how it would solve multiple domU accesses. For the second
paragraph, do you have recommended readings? frankly I don't completely
understand the solution any pointers appreciated.

In addition, registers in NIC are memory mapped(ioremap function is used,
and in ioctls memcpy_toio and memcpy_fromio is used to write/read registers)
and wanted  to know if its possible to map memory from dom0 into domU's? I
haven't looked into details of issues that will comeup with mapping, but
thought of checking. ioctl is one application which uses register
reads/writes and there are other modules(in kernel I believe) is being
developed which need register read/write functionality as well.

Thanks

Daniel
>
>
>
>
>
>
>

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

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

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