[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn]


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 29 Dec 2005 09:59:16 +0800
  • Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 29 Dec 2005 02:03:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcYHzbGsp/tYmOukSW+YY8FNtaIiYwALZ7OwAH5XjuAAggoFcAAAYWMQAAYlc4A=
  • Thread-topic: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn]

>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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.