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/
Home Products Support Community News


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

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] RE: [Xen-ia64-full 68] Fwd: Topics to for Xen Summit discussion
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Tue, 10 Jan 2006 16:16:42 +0900
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, jean-paul.pigache@xxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 10 Jan 2006 07:22:49 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD802C06C16@pdsmsx403>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <571ACEFD467F7749BC50E0A98C17CDD802C06C16@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/
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. 


Xen-ia64-devel mailing list