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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.