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-31 11:54, Paul Durrant wrote:
>> -----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
>> 
> 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.

I see that currently the function that maps the grant table itself
creates such "holes" with XENMEM_decrease_reservation.
> 
> 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

Thank you, I'll tinker some more and report what comes out of it.

- -- 
RafaÅ WojdyÅa
Qubes Tools for Windows developer
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJVGpFQAAoJEIWi9rB2GrW7zl8H/iiZOV99mEEluJfVsY/24XRB
y959r4pf56Lc2UnfpA9MMCRgMokQSp6Q7e5n9KGCZynVYkRrPXCSIgxrFt67CDC2
EvjoAQBC75vUyaPv3av8Xf+BEkYdRyTW9ljs6itDlaIpux57/Z6rMfqd/oKLhGA7
pfKf9xms8wfO8sVo3VNRrY2GGnI41Q4coW/37DtvQSgT+V8vIovp26Z5T6/do0zD
xHTI4il1qMk/FNLfHhSZcMiYjjPxKfs8BoZ0LV8+0dcz1qolpI/IecpEhjFV9aay
N2hDokNGqFF1eed8cYkclSXiZFxjfsmj+y3gwAu3tBRFihgJ64TvtusA6YNSXUI=
=ff6Q
-----END PGP SIGNATURE-----

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