| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] xc_domain_translate_gpfn_list vanished from unstable
On Jan 7, 2007, at 12:35 PM, Keir Fraser wrote:
On 7/1/07 5:27 pm, "Tomáš Kouba" <tomas@xxxxxxxx> wrote:
I am sorry, I don't understand one thing: if the translated-guest
addresses are always referenced by pseudo-physical address (or pfn?)
then why the "xc_map_foreign_range" has its last parameter as mfn and
not pfn?
xc_map_foreign_* functions all actually take 'gmfn' -- that is the
guest-apparent machine address. Paravirtualised guests usually see
machine
addresses, so gmfn==mfn. HVM guests have the translation done for
them by
the hypervisor, so they see gmfn==gpfn (guest pseudophysical frame
number).
Function prototypes and comments in xenctrl.h have unfortuantely
not been
updated to reflect this change.
Thanks for clearing this up, the xenctrl header and libxc source
code do not indicate that the "mfn" parameter
is in fact not an mfn but a gpfn.
But I think it has been causing me some difficulty.
I've been confused trying to map pages based on known guest virtual
addresses from HVM's
for some time. For paravirtualized guests this is as easy as using
xc_translate_foreign_address
followed by xc_map_foreign_range on the result, but this fails for
HVM's (changeset 13282:9865145e53eb)
when xc_translate_foreign_address claims that it is unable to map the
PD of the HVM.
Presumably this is because the cr3 value returned by
xc_vcpu_getcontext holds the machine frame number
page tables (presumably this is the guest cr3 so the page tables map
gvas to gpfns and not the host cr3 that
is used by the hardware to map gvas to gmfns).
Can you suggest an approach that would actually work?
thanks
-aaron
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home