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
|
Home