(Sending to broader list since we're touching more details now)
Hi, Yamahata,
Good to see your comments below and following is some in my mind:
>* 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.
> 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?
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.
>
> The current implementation allocates pages on demand.
> There is no difference that a page is not yet allocated or a page
> is not assigned(dom0 explicitly returned a page to xen).
> I'm not sure whether this cause problems. but if this cause subtle problem
> the demand allocation for dom0 can be disabled.
I think allocation on demand is originally introduced there due to lacking of
balloon support on XEN/IA64. Once we get balloon working after adding p2m
support, it's natural to align ia64 domain builder to other arch like x86,
meaning to allocate all pages when creating domain. Actually if dom0 can access
p2m directly, that also means we have to allocate all pages in the start. ;-)
> - writable page table
> I don't see any reason why this is needed.
Neither do I. Just list for possible discussion.
Thanks,
Kevin
>-----Original Message-----
>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年1月7日 20:31
>To: dan.magenheimer@xxxxxx; jean-paul.pigache@xxxxxxxx; Yang, Fred;
>y-oguchi@xxxxxxxxxxxxxx
>Cc: Tian, Kevin; xen-ia64-full@xxxxxxxxxxxxxxxx
>Subject: Re: [Xen-ia64-full 68] Fwd: Topics to for Xen Summit discussion
>
>
>Hi all.
>
>Evantually I can attend the summit and so the IA64 F2F meeting.
>Thank you very much.
>Oguchi-san of Fujitsu forworded the mail and reqeusted comments.
>Here is my comment.
>
>* vhpt management
> This issue isn't in the agenda.
> Is it thought as a post next-step issue?
> I think vhpt management is critical for the SMP-fication,
> and the non-VTI and VTI codes can be unified.
>
>* physical memory support
> I agree that phys2mach translation should be adopted.
>
> My implementation proposal is as follows.
> Just phys to mach translation is sufficient, and xen tracks their change.
> 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.
> 2. add a new hyper call which translates phys to mach.
>
> The current implementation allocates pages on demand.
> There is no difference that a page is not yet allocated or a page
> is not assigned(dom0 explicitly returned a page to xen).
> I'm not sure whether this cause problems. but if this cause subtle problem
> the demand allocation for dom0 can be disabled.
>
>* more memory enhancement
> - page reference count
> This is needed for domU debug, save/restore, migration.
> Foreign page mapping is also required.
>
>* timer virtualization
> This is not IA64 specific so that we should discuss about domain
> time subsystem modification with x86 (and other-arch) people.
> I think xen time management implementation can be improved.
>
>Thanks.
>
>On Sat, Jan 07, 2006 at 09:23:46AM +0900, Yoshi. Oguchi wrote:
>
>> I forward the mail from Yang, Fred:
>> Team,
>>
>> Attached is the draft foil for proposed topics we can discuss during
>> Summit F2F. New topics and Feedback, comments are welcomed!
>> We should also find a time to go dinner all together during summit. :-)
>> Thanks,
>>
>> -Fred
>
>--
>yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home