>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
>Sent: 2005年12月29日 6:43
>
>> > All such troubles come from no phys2mach mapping table within
>> > ia64 dom0! So Dan, maybe it's time to revise current ia64
>> > xenlinux design to make life easier. ;-)
>>
>> This is an important question. In my opinion, it may make
>> life easier to mimic the x86 memory management scheme. But
>> I believe one of the roles of Xen/ia64 as the first non-x86
>> port is to identify code existing in Xen and Xenlinux that
>> is x86-specific and help to define a better architecture-
>> independent interface. I think the whole concept of a
>> guest-visible phys2mach table is a necessary evil on x86
>> because the guest writes page tables that are walked by
>> hardware. This is of questionable use on other architectures
>> (and even on x86 in full shadow mode?).
>
>Question for core Xen developers and other arch Xen developers:
>
>As we evolve toward architecture-neutral APIs within Xen,
>within paravirtualized Xenlinux, and between Xen and
>paravirtualized Xenlinux, should a guest-visible physical-to-
>machine mapping table be a necessary part of the arch-neutral API?
>Or is this concept a useful mechanism for the x86 family only that
>should not be propagated to other Xen architectures?
Hi, Dan,
IMO, I see the phys2mach mapping as a basic virtualization policy,
instead of an architecture specific requirement. After adding phys2mach concept
to XEN/IA64, we can reuse more common code without ifdef. Then correspondingly
also need to add several necessary changes like x86: DMA, SWIOTLB, AGP, etc, to
ensure legal machine address written into physical devices.
For writable page table, it's safe to skip it now even after adding
phys2mach, since software managed page table is not walked by IA64 processor
directly. Later we may evaluate necessity and performance gain after most
things done.
With major policy consistent and more code shared, XEN/IA64 then can
really help XEN better run on more architectures. ;-)
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home