Xen devel - Apr 2007 - question about memory auto-translate and paravirtual and no pseudophysical overlay

hi
 I try to understand the code of xen memory
 there are gmfn, gpfn and pfn  in the xen
and in the /xen/include/xen/mm.h  there are some explanation about them 
as follows:

 * 1. gpfn/gpaddr: A guest-specific pseudo-physical frame number or address.
 * 2. gmfn/gmaddr: A machine address from the p.o.v. of a particular guest.
 * 3. mfn/maddr:   A real machine frame number or address.
 * 4. pfn/paddr:   Used in ''polymorphic'' functions that work
across all
 *                 address spaces, depending on context. See the pagetable
 *                 conversion macros in asm-x86/page.h for examples.
 *                 Also ''paddr_t'' is big enough to store any
physical
address.
 *

I seems to understand the meaning about them,but I am confused about  
the different memory-management modes as follows

 * This scheme provides consistent function and variable names even when
 * different guests are running in different memory-management modes.
 * 1. A guest running in auto-translated mode (e.g., 
shadow_mode_translate())
 *    will have gpfn == gmfn and gmfn != mfn.
 * 2. A paravirtualised x86 guest will have gpfn != gmfn and gmfn == mfn.
 * 3. A paravirtualised guest with no pseudophysical overlay will have
 *    gpfn == gpmfn == mfn.
 *

what is the meaning about auto-translated mode,is it not the same with 
paravirtualised one ?
does the auto-translated mode work for hvm and shadow mode? how does it 
work?
and what is the mechanism about paravirtualised guest with no 
pseudophysical overlay?

I am confused about it

could you help me
Thanks in advance




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

hi
I try to understand the code of xen memory ,and I am confused  about  
the  memory-management modes,could someone help me
 
there are gmfn, gpfn and pfn  in the xen ,and in the 
/xen/include/xen/mm.h  there are some explanation about them as follows:

* 1. gpfn/gpaddr: A guest-specific pseudo-physical frame number or address.
* 2. gmfn/gmaddr: A machine address from the p.o.v. of a particular guest.
* 3. mfn/maddr:   A real machine frame number or address.
* 4. pfn/paddr:   Used in ''polymorphic'' functions that work
across all
*                 address spaces, depending on context. See the pagetable
*                 conversion macros in asm-x86/page.h for examples.
*                 Also ''paddr_t'' is big enough to store any
physical
address.
*

I seems to understand the meaning about them,but I am confused about  
the different memory-management modes as follows

* This scheme provides consistent function and variable names even when
* different guests are running in different memory-management modes.
* 1. A guest running in auto-translated mode (e.g., 
shadow_mode_translate())
*    will have gpfn == gmfn and gmfn != mfn.
* 2. A paravirtualised x86 guest will have gpfn != gmfn and gmfn == mfn.
* 3. A paravirtualised guest with no pseudophysical overlay will have
*    gpfn == gpmfn == mfn.
*

what is the meaning about auto-translated mode,is it not the same with 
paravirtualised one ?
does the auto-translated mode work for hvm and shadow mode? how does it 
work?
and what is the mechanism about paravirtualised guest with no 
pseudophysical overlay?

I am confused about it

could you help me
Thanks in advance


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

> * This scheme provides consistent function and variable names even when
> * different guests are running in different memory-management modes.
> * 1. A guest running in auto-translated mode (e.g., 
> shadow_mode_translate())
> *    will have gpfn == gmfn and gmfn != mfn.
> * 2. A paravirtualised x86 guest will have gpfn != gmfn and gmfn == mfn.
> * 3. A paravirtualised guest with no pseudophysical overlay will have
> *    gpfn == gpmfn == mfn.
> *
> 
> what is the meaning about auto-translated mode,is it not the same with 
> paravirtualised one ?
An auto-translated paravirtualised guest could be Xen-aware in its
memory management code but Xen would be hiding the underlying memory
layout from it.  This is not the normal case - I''m not actually sure
it''s supported these days, although it has worked in the past.

Essentially, though and autotranslated guest doesn''t need to have any
awareness of the machine memory layout, it can just pretend its got all
the memory.
> does the auto-translated mode work for hvm and shadow mode? how does it 
> work?
HVM also has a version of autotranslate mode (does it have another name
for HVM?  I''m not sure...) - HVM guests always expect that they own
*all* the memory in the machine, so they need to have the real memory
layout concealed from them.  This is done by shadowing the guest''s
pagetables so that a gmfn->mfn translation can be applied to them before
inserting them into the real pagetables.
> and what is the mechanism about paravirtualised guest with no 
> pseudophysical overlay?
This would be a guest that didn''t use the abstraction of pseudophysical
addresses at all; it would just use virtual and (real) machine
addresses.  I''m not sure if there are any guests that operate in this
way...  Certainly the major heavyweight OSes all use this technique when
paravirtualised.

HTH,
Cheers,
Mark


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

Thank you for your reply

Mark Williamson 写道:
> This would be a guest that didn''t use the abstraction of
pseudophysical
> addresses at all; it would just use virtual and (real) machine
> addresses.  I''m not sure if there are any guests that operate in
this
> way...  Certainly the major heavyweight OSes all use this technique when
> paravirtualised.
>
>   
what is the major heavyweight OSes? and how does it paravirtualise?
if there is no pseudophysical addresses,a physical host computer could
only paravirtualise one VM,is it right?



Thank you in advance
>
>   

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

> Mark Williamson 写道:
> > This would be a guest that didn''t use the abstraction of
pseudophysical
> > addresses at all; it would just use virtual and (real) machine
> > addresses.  I''m not sure if there are any guests that operate
in this
> > way...  Certainly the major heavyweight OSes all use this technique
when
> > paravirtualised.
>
> what is the major heavyweight OSes?
I was referring to the full general purpose OSes that have been ported to Xen, 
i.e.: Linux, NetBSD, Solaris, etc.
> and how does it paravirtualise? 
These all use pseudophysical addresses to maintain the abstraction of a 
vaguely "normal" memory model for their core memory management code to
work
with, then the Xen architecture code in each OS translates these into real 
machine addresses so that everything works properly.
> if there is no pseudophysical addresses,a physical host computer could
> only paravirtualise one VM,is it right?
No, AFAIK pseudophysical addresses are mostly there for the convenience of the 
guest.  Xen has some support for them so that guests can use them more 
efficiently but that''s not strictly necessary.  In principle, they
could be
eliminated from Xen entirely (would require modifying the PV guests to manage 
the pseudophys abstraction themselves).

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

hi
Thank you for your reply


Mark Williamson 写道:
>> if there is no pseudophysical addresses,a physical host computer could
>> only paravirtualise one VM,is it right?
>>     
>
> No, AFAIK pseudophysical addresses are mostly there for the convenience of
the
> guest.  Xen has some support for them so that guests can use them more 
> efficiently but that''s not strictly necessary.  In principle, they
could be
> eliminated from Xen entirely (would require modifying the PV guests to
manage
> the pseudophys abstraction themselves).
>   
Is there this kind paravirtual os for xen at present?
or in future,will this kind paravirtual os come out?
and what is the advantages for this kind of os?

Thanks in advance

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

Nb. I''m focussing on x86 (and x86_32 where appropriate) here and have
been in
the rest of the thread (unless otherwise specified)...  other architectures 
deal with pseudophysical addressses differently.
> Mark Williamson 写道:
> >> if there is no pseudophysical addresses,a physical host computer
could
> >> only paravirtualise one VM,is it right?
> >
> > No, AFAIK pseudophysical addresses are mostly there for the
convenience
> > of the guest.  Xen has some support for them so that guests can use
them
> > more efficiently but that''s not strictly necessary.  In
principle, they
> > could be eliminated from Xen entirely (would require modifying the PV
> > guests to manage the pseudophys abstraction themselves).
>
> Is there this kind paravirtual os for xen at present?
> or in future,will this kind paravirtual os come out?
> and what is the advantages for this kind of os?
There''s two aspects to this answer, I guess:

1) Will guests which maintain their own pseudophysical abstraction rather than 
using Xen''s be written?  /  Will Xen''s pseudophysical support
be removed?

This isn''t likely for the timebeing; Xen needs to incorporate the 
pseudophysical support it has for backwards-compatibility purposes and given 
that there''s no reason for guests not to use it.

2) Will guests that don''t use a pseudophysical abstraction at all be
written?

I don''t know if anyone has written / ported an OS that does this...  I 
wouldn''t expect to see any general purpose OSes using this for a while
- they
typically seem to need the pseudophysical abstraction to keep their generic 
memory management code happy.

More minimal, special purposes OSes (especially if targetted to Xen) might be 
able to do away with pseudophysical addresses entirely and just use virtual 
and machine addresses.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

Thank you for your reply

Thank you


Mark Williamson 写道:
> Nb. I''m focussing on x86 (and x86_32 where appropriate) here and
have been in
> the rest of the thread (unless otherwise specified)...  other architectures
> deal with pseudophysical addressses differently.
>
>   
>> Mark Williamson 写道:
>>     
>>>> if there is no pseudophysical addresses,a physical host
computer could
>>>> only paravirtualise one VM,is it right?
>>>>         
>>> No, AFAIK pseudophysical addresses are mostly there for the
convenience
>>> of the guest.  Xen has some support for them so that guests can use
them
>>> more efficiently but that''s not strictly necessary.  In
principle, they
>>> could be eliminated from Xen entirely (would require modifying the
PV
>>> guests to manage the pseudophys abstraction themselves).
>>>       
>> Is there this kind paravirtual os for xen at present?
>> or in future,will this kind paravirtual os come out?
>> and what is the advantages for this kind of os?
>>     
>
> There''s two aspects to this answer, I guess:
>
> 1) Will guests which maintain their own pseudophysical abstraction rather
than
> using Xen''s be written?  /  Will Xen''s pseudophysical
support be removed?
>
> This isn''t likely for the timebeing; Xen needs to incorporate the 
> pseudophysical support it has for backwards-compatibility purposes and
given
> that there''s no reason for guests not to use it.
>
> 2) Will guests that don''t use a pseudophysical abstraction at all
be written?
>
> I don''t know if anyone has written / ported an OS that does
this...  I
> wouldn''t expect to see any general purpose OSes using this for a
while - they
> typically seem to need the pseudophysical abstraction to keep their generic
> memory management code happy.
>
> More minimal, special purposes OSes (especially if targetted to Xen) might
be
> able to do away with pseudophysical addresses entirely and just use virtual
> and machine addresses.
>
> Cheers,
> Mark
>
>   

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