Xen devel - Jan 2007 - xc_domain_translate_gpfn_list vanished from unstable

Hello,
in xen-3.0.3 there was function xc_domain_translate_gpfn_list in libxc
but it is not in unstable now. I have checked `hg log` but cannot find
the patch that did it (and would explain).
Can somebody point me to the patch, or mail that discussed this removal
(I was unable to find it either :( )

Thank you

--
Tomas Kouba

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/1/07 1:39 am, "Tomáš Kouba" <tomas@jikos.cz> wrote:
> in xen-3.0.3 there was function xc_domain_translate_gpfn_list in libxc
> but it is not in unstable now. I have checked `hg log` but cannot find
> the patch that did it (and would explain).
> Can somebody point me to the patch, or mail that discussed this removal
> (I was unable to find it either :( )
This was part of a cleanup in which translated-guest addresses are always
referenced by pseudo-physical address rather than machine address. The
function is still provided by Xen (for compatibility) but it shouldn''t
be
needed by tools any more.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 7/1/07 1:39 am, "Tomáš Kouba" <tomas@jikos.cz> wrote:
> 
>> in xen-3.0.3 there was function xc_domain_translate_gpfn_list in libxc
>> but it is not in unstable now. I have checked `hg log` but cannot find
>> the patch that did it (and would explain).
>> Can somebody point me to the patch, or mail that discussed this removal
>> (I was unable to find it either :( )
> 
> This was part of a cleanup in which translated-guest addresses are always
> referenced by pseudo-physical address rather than machine address. The
> function is still provided by Xen (for compatibility) but it
shouldn''t be
> needed by tools any more.
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?

Thank you

--
Tomas Kouba


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/1/07 5:27 pm, "Tomáš Kouba" <tomas@jikos.cz> 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.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> On 7/1/07 1:39 am, "Tomáš Kouba" <tomas@jikos.cz> wrote:
> 
>> in xen-3.0.3 there was function xc_domain_translate_gpfn_list in libxc
>> but it is not in unstable now. I have checked `hg log` but cannot find
>> the patch that did it (and would explain).
>> Can somebody point me to the patch, or mail that discussed this removal
>> (I was unable to find it either :( )
> 
> This was part of a cleanup in which translated-guest addresses are always
> referenced by pseudo-physical address rather than machine address. The
> function is still provided by Xen (for compatibility) but it
shouldn''t be
> needed by tools any more.
Is there some versioning of libxc interface? I see just 
__XEN_INTERFACE_VERSION__ which works for hypervisor iface.
I think similar thing for libxc would be handy too (I believe more tools
use its API to access xen).

-- 
Tomas Kouba

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Jan 7, 2007, at 12:35 PM, Keir Fraser wrote:
> On 7/1/07 5:27 pm, "Tomáš Kouba" <tomas@jikos.cz> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 9/1/07 20:48, "James Pendergrass"
<James.Pendergrass@jhuapl.edu> wrote:
> 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).
No, CR3 is a pseudophysical address (it''s the value that the guest
wrote,
with no translation done on it). If the failure message mentions
''PD'' rather
than ''PML4'' then I think it''s the table 2 levels down
that isn''t getting
mapped. Add some extra tracing to the function and check that the PDEs
you''ve seen on the pagetable walk actually look sane.
> Can you suggest an approach that would actually work?
Expect to need to fix up functions in libxc. Some of these are only used by
debug/diagnostic tools so they''re not always up to date.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel