[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Mapping shared pages from Windows
> Hi all, > > I have been working on my little OS port and things seem to be going > reasonably OK. I am writing it from the ground up using David Chisnall's book > "The Definitive Guide to the Xen Hypervisor" and referring to the mini-os > implementation. I find there are too many dependencies and additional bits > in the mini-os code to just pull the bits out that I need. Maybe once I've > got a > better understanding I'll be able to go back and do something there. > > My next channel is to talk to my little OS from a Windows HVM. As a start I > have offered a shared page from my domain which I want to map in a little > Windows app. > > I have been looking for a Windows API to access Xen, but I haven't found > anything. I took a quick look at the GPLPV drivers but that is quite a large > set > of files. Is there an easier starting point, and maybe even a little > documentation? > Under GPLPV, everything is currently done via mapping a page from Windows into Dom0 (or driver domain). Apart from a few cases at startup I don't think I map any foreign pages into Windows. The typical design of a xen driver (eg net/disk) is that you have a shared page for the io ring, an event channel for the front and backend drivers to deliver events to each other, and then the messages on the io ring may include grant references to other pages of memory for buffer passing. I think it would be possible to map a foreign page into Windows by swapping out the pfn of the foreign page with a windows page, or maybe to map it into the windows io space designated by the pci device used for interrupt delivery (although that is a limited resource). The other thing is that pretty much all of this happens in kernel space. Mapping a page of memory from Windows kernel to user space is something you'd probably try and avoid if possible (read ntdev archives for many, many opinions on this :) Mapping a page from userspace into xen would be better, but then your os would need to handle mapping the page from windows. I'll ask on the ntdev list about this as I'm curious now... GPLPV has some basic xenbus functionality available from userspace (enough for the shutdownmon app to detect that dom0 has requested a shutdown/reboot/whatever), but no functionality for event channel or grant table calls. Ideally these would be implemented in GPLPV to match the ioctl's that Linux uses and so the api libraries could be ported across, but that's a bit of work and I haven't had a need to do it so far. So... what are you going to do with this shared memory you are mapping? Does it need an associated event channel? Will it be a shared io ring with other mapped pages or will you just be passing tiny messages? If you are just passing tiny messages, and there isn't any particular performance requirements, maybe you could use xenbus to write into the xenstore and pass messages that way. A message every few seconds would be fine. 100 messages a second via xenbus might be too much. I'm happy to fix any bugs or shortcomings you find in the GPLPV side of the xenbus code. And I can look at adding event channel and page passing (which would allow a complete device implementation in userspace), but no guarantee I will be able to get anything done quickly. And you'd either need to handle the IOCTL calls yourself, or port over the various libraries from xen (the IOCTL's are pretty raw). James _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |