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

[RafaÅ WojdyÅa <omeg@xxxxxxxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-03-11 18:46, Paul Durrant wrote:
>> -----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
>> 
> 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/msg0006
0.
>
> 
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.
> 
I've tested the drivers on a Win7 pro x64 HVM on Qubes r2 (r3 is still
a bit unstable). Xenbus and xeniface both install fine. Xenvbd
installs OK but the OS BSODs on reboot with code 7B (inaccessible boot
device). I'll try to pinpoint the exact failure spot once I setup the
pvdrivers sources inside my development VM.

Do the drivers have specific requirements for backend (Xen/Qemu
version)? We're not really using Qemu in dom0, only in minimal
stubdoms for HVMs, so that may be a problem.

>> Cheers,
> 
>> Paul
> 
> Cheers,
> 
- -- 
RafaÅ WojdyÅa
Qubes Tools for Windows developer
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJVAbvvAAoJEIWi9rB2GrW7hxkH+wbkkpYfcBqcUktWg7jdOZzf
fgJMuRRPwg6sotT+EDvKR4JsDo2Mj46jaw8HCuet5ncfMzr8zCEH0gSOEoHg9DZ8
fJOtUzkZBglYob+bVn2zbW1jLd8LrNnygyMARUw5DGCpusqXKQ1lF70sMsANti2R
4AymHbjb2Gw2Rckgnc+FQmuGb8/9zATqNCQLZs5yIYQ3kE4vdVtTvjASKyjz6r5B
DVfBkJ8/EYgbJBUosNAlNdqb2MikeYAq6+a94e8kvZXe95pDjeZxp6WSCGDasINQ
9d1aD96+JsPidCaifgcbQQiNNI7hLV4a+4Ku/blfnXGAC3sMqv+hc8b4/6t8mGs=
=TsIg
-----END PGP SIGNATURE-----

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel