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

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

Hash: SHA1

On 2015-03-12 17:45, Paul Durrant wrote:
>> -----Original Message----- From: RafaÅ WojdyÅa
>> [mailto:omeg@xxxxxxxxxxxxxxxxxxxxxx] Sent: 12 March 2015 16:17 
>> To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx Subject: Re:
>> [win-pv-devel] Porting libvchan to use the Windows PV Drivers
> 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/msg0
> 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.
>> 0x7B can occur in many circumstances. The drivers do log quite a
>> bit of info, particularly in checked builds, so there'll probably
>> be something there to indicate the exact nature of the failure.
>> The main informational logging (which is the same for free or
>> checked builds) is written to the qemu logging port (0x12) and
>> debug logging (checked build only) goes to the Xen port (0xE9).
>> If you watch wherever you have those redirected then you may be
>> able to spot the problem. If you can't then post them to the list
>> and I'll take a look.
> 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.
>> That's not usually a problem. Do you have PV backends for disk
>> and net set up though? The fact that you got a 0x7B after
>> installing xenvbd may simply mean that your toolstack has just
>> not set up a PV backend.
We do have backends set up (xen-blkback for vbd). I'll check in dom0
whether it crashes after the device gets attached or before.

Also adding Marek to the conversation, he's one of our core architects
and knows more about backend stuff than I do :)

>> Paul

- -- 
RafaÅ WojdyÅa
Qubes Tools for Windows developer


win-pv-devel mailing list



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