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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: RafaÅ WojdyÅa [mailto:omeg@xxxxxxxxxxxxxxxxxxxxxx]
> Sent: 31 March 2015 06:51
> To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [win-pv-devel] Porting libvchan to use the Windows PV Drivers
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> After some thought I've decided to implement the missing pieces in the
> GPLPV drivers first, mostly to not do many things at once (like
> porting our Windows tools to use the new drivers, changing our build
> process etc). I'll definitely test the new drivers once Qubes r3
> becomes more stable.
> 

Ok, fair enough.

> I have some questions though, mostly on the topic of Xen's grant
> mapping and memory hypercalls. As I wrote before, I'm a newcomer to
> Xen API on this level and to me the existing documentation seems
> pretty impenetrable. The overall picture is mostly clear, but many
> important details seem missing.
> 
> Let's take the GNTTABOP_map_grant_ref call. In the header we see:
> 
> If GNTMAP_host_map is specified then a mapping will be added at
>  *     either a host virtual address in the current address space, or at
>  *     a PTE at the specified machine address.  The type of mapping to
>  *     perform is selected through the GNTMAP_contains_pte flag, and the
>  *     address is specified in <host_addr>.
> 
> I'm passing GNTMAP_host_map flag, but what type of address should be
> passed for the mapped page? The section above says "mapping will be
> added at either a host virtual address..." but I doubt a VA is wanted,
> because I'd need to allocate some kernel memory to pass a VA to this
> call, and allocation means mapping in itself. Should this be a
> physical address? A PFN? Something else entirely?
> 

Hypercalls on HVM guests usually deal in GFNs. There's basically no way for an 
HVM guest to get hold of MFN values. PV guests OTOH deal in MFNs.

> After reading some Linux code that uses this call I saw that it
> "allocated" the address for the mapped page via the balloon driver. On
> Windows this means getting a page from Xen via
> XENMEM_increase_reservation as far as I know.

Unless your toolstack is allocating extra memory that's not already in the 
guest P2M then that's going to fail. I think what you probably want to do is 
either find a 'hole' (i.e. GFNs not populated with RAM) such as the Xen 
Platform PCI device's BAR space, or create a hole using decrease_reservation. 
Either way, you'll have a GFN in your hand.

> But then again:
> XENMEM_increase_reservation returns a MFN of the allocated page. What
> good is this for the above purpose? If I understand correctly, a HVM
> doesn't know real MFNs. Should I translate such MFN into a GMFN/GPFN
> and then pass it to GNTTABOP_map_grant_ref as the address? If so, how
> to perform such translation?
> 
> I experimented with some XENMEM hypercalls.
> XENMEM_machphys_mapping
> "returns the location in virtual address space of the machine_to_phys
> mapping table", but the structure and meaning of such table is not
> explained. I assume it translates real MFNs into GMFNs in some way.
> The call succeedes with following output values:
> 
> v_start  0xffff8000`00000000
> v_end    0xffff8040`00000000
> max_mfn  0x00000007`ffffffff
> 
> ...but that VA range appears to be not accessible/not mapped.
> 
> XENMEM_machphys_mfn_list call also worked and returned a list of 9
> values on my test HVM (Win7 x64 with 1GB of RAM). I'm not really sure
> what to make of them, the description isn't very helpful for someone
> who doesn't already know how this works: "Returns a list of MFN bases
> of 2MB extents comprising the machine_to_phys mapping table".
> 
> Maybe I'm overcomplicating things and overlooked something obvious.
> I'd welcome any corrections and/or hints :)

Yeah, I think you're overcomplicating things :-) See above.

  Paul

> 
> - --
> RafaÅ WojdyÅa
> Qubes Tools for Windows developer
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBAgAGBQJVGjXGAAoJEIWi9rB2GrW77sQIALD6o+i9kCDEi5bilC7EVbn
> Q
> aCOxQytarnoKKc7uG3PlHqbxGYR+cPKbzCEDrXH90MkFMk17L/bsSYhpT7ST8E
> mZ
> QoRdVu7EPT52XIWDqYQZT/BJwIl6kXNEi6JXOp5dlCKWnCFWkpgP+iynrAOmu
> 0in
> Z04sQBLP0jwsTgoPdeBPyGV6rwd8zdcjY3GGd4p0LHistW01R1+5quhSptbzieq
> E
> /lkjLSTBEDJXym7npxKrE/WsfzfFzjai0YJoONEf5n/HjCbFPZgYQaw4L00J+2s5
> lna7z8E//8kFyyyT+CKqlqr2Mw6hLJkjjGDifgdnJ9525TKintLy7PXFMaauBcM=
> =Soff
> -----END PGP SIGNATURE-----
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel