[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

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.

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?

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. 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 :)

- -- 
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®.