| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] RE: [Xen-ia64-full 68] Fwd: Topics to for Xen Summi
>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年1月10日 15:17
>> > 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.
Yes.
> - 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.)
Yes, that's one place you may need to grep carefully. IIRC, sometimes xenlinux
may simply change the phys_to_mach table to INVALID_P2M_ENTRY without
notification to Xen if guest pfn is free. Anyway, I think final goal is to
minimize architecture bias in common driver code, and if you can do that
cleanly then it's OK. I think Keir and Ian have clearest vision on this point.
;-)
> - 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?
No, I mostly agree with your approach on this issue with just one difference: I
would like to see phys2mach mapping ptes allocated within domain's configured
memory, instead of by Xen. Then you need to modify construct_dom0 and control
panel to construct those ptes. Then Later Xen just constructs its multi-level
page tables with phys2mach table as L1 directly. By this way, dom0 owns the
memory and thus dom0 setups the mapping within its own range. I always think
dom0 has better knowledge about how allocated resource will be final utilized
and better to let dom0 to setup such stuff by its normal way instead of Xen's
supplement.
If we do this way, it's natural to let dom0 modify phys2mach table directly,
right?
Thanks,
Kevin
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home