WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

[Xen-ia64-devel] Re: pv_ops progress & ask for suggestion

On Tue, Apr 08, 2008 at 10:31:20AM +0800, Dong, Eddie wrote:
> >>    Now we have 2 choices:
> >>    Alt1:  Dual compile entry.S like IVT.s (dual compile all ASM
> >> files if it needs virtualization)
> >>            pros: Same policy with iVT, use same MACRO to
> >> replacement.
> >>            cons: There are other ASM files such as
> >> sn/kernel/pio_phys.S need to be dual compiled too.
> >>                    And unlike IVT table, the memory occupied by
> >> dual compiled code won't be able to be freed easily since the size is
> >> not fixed. Also all future ASM code touch privilege instruction may
> >> need to be dual compiled too.
> > 
> > I suppose the more generalized problem is
> > - The memory for unused pv code/data won't be executed/referenced
> >   so that it can be freed somehow.
> >   Is it worth while to do that? And how to do it?
> 
> For IVT table (64K) & gate page (1 page), it can be done except
> relocating
> those IP relative symbols.

Yes, IVT table and gate page is somewhat special so that they are
worth while to handle specialy.


> > This is not ia64 specific issues, and should be addressed
> > in arch generic way. This hasn't been addressed even on x86.
> 
> X86 doesn't use dual compile.

I meant by "more generalized" that freeing not only dual compiled
ones, but also all ones under xen directory (or lguest, vmi... on x86).

-- 
yamahata

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

<Prev in Thread] Current Thread [Next in Thread>