Re: [Xen-ia64-devel] RE: [Xen-ia64-full 68] Fwd: Topics to for Xen Summit discussion

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

Hi Kevin.

On Mon, Jan 09, 2006 at 03:07:38PM +0800, Tian, Kevin wrote:

> >* physical memory support
> >  I agree that phys2mach translation should be adopted.
> 
> Yes.
> 
> >
> >  My implementation proposal is as follows.
> >  Just phys to mach translation is sufficient, and xen tracks their change.
> 
> Not sure what you mean by "sufficient"? ;-) Just a reminder that once p2m 
> concept is added, we have to promise all places aware of existence of this 
> translation if really required, including some core-header files (like DMA) 
> besides para-drivers. Code there has to explicit query this translation by 
> either direct access or hypercall.

My more detailed idea to implement the phys2mach is as follows.

* observation
  - xenlinux/X86 maintains phys2table conversion by itself. not by xen.
    the memory area used for the table is maintained by xenlinux and
    the table is writable for xenlinux.
  - By grepping xenlinux code, I observed that xenlinux modifiles 
    the phys2mach table via set_phys_to_machine() and that 
    set_phys_to_machine() calls are paired with hypercalls
    (xen_machphys_update(), memory op, grant table, update va mapping).
    So I gussed dom0 don't have to write the phys2mach table directly.
    (I can easily miss important things, so I may be wrong.)
  - xen/ia64 already tracks phys2mach conversion by struct arch_domain::mm.
    (currently for domU. dom0 is an exception for now)

* my implementation proposal
  - map xen's arch_domain::mm pte pages to dom0 virtual address space 
    linearly with read-only protection.
    Since pte pages are managed by xen, I think it is reasonable for xen 
    to handles tlb miss by dom0 on the phys2mach table area.
  - leave set_phys_to_machine() as nop.

You seem to have different ideas.
Do you think that it is needed for dom0 to write phys2mach table directly?


> >  There are two implementation candidates.
> >  1. map xen's translation table to dom0 address space like virtual memmap.
> >     Xen handles tlb miss fault to the area instead of dom0.
> >     If dom0 get tlb miss in the area, the mfs is considered INVALID_MFN.
> >     There is a choice to determine the mapping address.
> >     - Xen determines the address, and pass it to dom0 as boot parameter
> >     - add a hyper call for dom0 to map the table at the requested address.
> 
> Could you give a reason why you want Xen to intercept the tlb miss upon that 
> area, instead of letting dom0 manage it directly?
> 
> Since dom0 is anyhow aware of such virtual area, that means dom0 has to 
> allocate and reserve that virtual range explicitly. Xen is not the right one 
> to decide the mapping address out of xenlinux's knowledge. So we still need 
> modify dom0's init code to do such reservation effort. Since that, why not 
> let dom0 setup the mapping itself?

I hope that the above answers these questions.


> Furthermore, there're several cases that xenlinux may shrink/expand the 
> memmap:
>       - Xenlinux may truncate the EFI memmap by some granularity. 
> 
>       - Xenlinux may expand the max pfn to compensate request from backend 
> which may require some empty physical frames.
> 
> Yes, we can add hypercall to let dom0/Xen sync with such info. But there 
> seems no necessity to do that.
> 
> >  2. add a new hyper call which translates phys to mach.
> 
> For performance reason, I prefer to let dom0 access that table directly.

I agreed. 


thanks.
-- 
yamahata

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