On Mon, 2010-02-22 at 12:36 -0500, Ritu kaur wrote:
>
> 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.
My understanding after catching up a little on the past of this thread
was that you want the network controller in some maintenance mode. Is
this correct?
To get it there you will need to temporarily remove it from the virtual
network topology.
The PCI passthrough mode might solve your second problem, which is how
the domU is supposed to access the device once it's been pulled off the
data path.
> 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?
Yes. This is the third problem, which is how to program a device. I'd
recommend "Linux Device Drivers" on that subject. There are also free
books like http://tldp.org/LDP/tlk/tlk-title.html. Examples likely
outdate, but the concepts remain.
If the device is memory mapped, it doesn't mean it's in memory. It means
it's in the machine memory address space. The difference should become
clear once you're done with understanding your driver.
Is this the reason why you are so concerned about the memory sharing
mechanism? The good news is now you won't need to bother, that's only
for memory. :)
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home