Re: [Xen-devel] Shared memory and event channel

[Daniel Stodden <daniel.stodden@xxxxxxxxxx>]

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.

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

Daniel







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