[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Shared memory and event channel
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |