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

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?


 -- Keir

Xen-devel mailing list

Xen-devel mailing list



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