[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [win-pv-devel] Porting libvchan to use the Windows PV Drivers



> -----Original Message-----
> From: win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:win-pv-devel-
> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Rafal Wojdyla
> Sent: 10 March 2015 20:16
> To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [win-pv-devel] Porting libvchan to use the Windows PV Drivers
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 

Hi,

> I'm unable to properly reply to the thread since I just subscribed to
> this list but I figured it's worth chiming in (last message is here:
> http://lists.xenproject.org/archives/html/win-pv-devel/2015-01/msg00060.
> html)
> 

  Yes, I understand; I just saw your subscription message :-)

> First, some background about me. I'm currently the main and pretty
> much the only developer/maintainer of guest tools for Windows for
> Qubes OS (https://wiki.qubes-os.org/). Some of you may have heard of
> Qubes -- in short, it's an attempt at creating a secure OS based on
> lightweight AppVMs, currently using Linux/Xen as base. It supports
> Windows HVMs and our guest tools provide integration with dom0/other
> domUs (services like data transfer, remote execution, seamless GUI
> experience etc).
> 

  Cool.

> We're in the process of finalizing the next major release (r3) of
> Qubes, it will use Xen 4.4 instead of r2's Xen 4.1. As for our Windows
> tools, they are (currently) using PV drivers based on James Harper's cod
> e.
> 
> Our inter-VM communication protocol uses vchan (in fact, vchan
> originates from our patch accepted into Xen's source a few years ago).
> In Qubes r2 we have a Windows libvchan implementation, but as stated
> above, it uses old PV drivers interfaces. You can find it here:
> https://github.com/QubesOS/qubes-core-vchan-xen
> 
> That implementation has one big flaw: client side vchan functions are
> not implemented. It didn't matter for Qubes r2, where all vchan
> communication is passing through dom0 anyway. In Qubes r3 however, we
> need that working because of redesigned inter-VM communication
> protocol that allows direct VM-VM communication after dom0 arbitration.
> 
> Unfortunately Harper's drivers don't seem to implement the needed
> kernel interfaces for that as well.

I assume you mean grant mapping? Or maybe just grant copy, since that would be 
safer?

> I didn't need to look into PV
> drivers sources before, but it seems I will need to do that now :) I
> found the new PV drivers and this mailing list, found the thread about
> vchan implementation... and that's pretty much it for now.
> 
> As I said, I don't have much experience in Xen APIs (didn't need to
> tinker with them directly before). I do, however, have extensive
> WinAPI knowledge and moderate amount of Windows driver development
> experience (part of our guest tools is a custom display driver that
> allows no-copy video memory sharing with dom0). I managed to build the
> new drivers and will test them on our dev Qubes build soon.
> 
> So, to summarize, I'm very interested in developing a Windows vchan
> implementation on top of the new PV drivers. I'll be reading through
> the driver sources for a bit still to familiarize myself with the
> environment. If anyone managed to get something working, or just has
> ideas, let me know.
> 

If you want to look at adding the necessary code to the XENBUS_GNTTAB interface 
to do grant map/copy then I don't imagine it will be too hard. Adding support 
for copy would be easiest but it would also be possible to grant map pages into 
the platform PCI device's BAR (which is where the shared info page and the 
grant table itself live).

Let me know if have any specific questions or need some help getting the 
drivers going in your environment.

  Cheers,

    Paul

> Cheers,
> 
> - --
> RafaÅ WojdyÅa
> Qubes Tools for Windows developer
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBAgAGBQJU/1D/AAoJEIWi9rB2GrW7VHQH/2vgwKTA4xJoezZB+vxC+
> UND
> f7HkvDcVDKfFHROkwWHqq7flnxFLj618HLrXZxtmrrZa30S1cC+XQxsOqXi4iopZ
> oPBRDyhjWyVo5mbuht0cAXy/nfRxE026Z0ozCfmvrpbXZe94G+w1O/ta7fWW/
> T/B
> PQDDl0oAcriTdZM9KuSfNP492vrLVM6iNj3u7QmpV6YVLPDeUKpggNF0gj+O0
> Lna
> NeFelO9cuCB1ETkuWfj1r5PvAptZMdqUl8DlgnpxIU8ep4AoWqI5g2UqeL6hBB
> 7H
> 2vGoI5H4ZY2uGX9mC1maukZ/rQX3tOodNswZDhopKkZxY16KRDb+6RF0fQ4l3
> 6E=
> =v9Jv
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> win-pv-devel mailing list
> win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel

 


Rackspace

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