[Xen-ia64-devel] RE: Xen/ia64 - global or per VP VHPT

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Magenheimer, Dan (HP Labs Fort Collins) wrote:
>> How can you guarantee the MAP for hypercall will not be
>> purged without extra data structure I mean vTLB?
> 
> I haven't seen your hypercall implementation yet, but I was
> assuming that (on non-VT) the parameters would be passed in
> memory in the "shared page" which is always mapped by a TR.
That may be true for XENOlinux, but how about non modified guest?
Both hypercall shared page, ForeignMap needs to be pinned by TR in this
solution. Further more, the ForeignMap is usually used to map all guest
memory space that may be 16GB or even 64GB in your example. While TR can
only cover 256MB, so HV needs 64TRs for that. It is impossible in
current IPF architecture.
So my point is to support non modified guest in global VHPT solution is
difficult, it needs extra data structure that eventually will be same
with our implementation except you want to exclude non modified guest.
> 
> Actually the current implementation does include a vTLB
> implementation, but it is one entry vITLB and one entry
> vDTLB, used so far only to ensure forward progress on
> privop emulation.
Eventually you needs to track a lot of vTLB like foreignmap entry (Per
domain basis). Will you still use scattered variable? I am using hash
data same with VHPT.
> 
> This is insufficient if your hypercall proposal passes parameters
> by address where the address can be anywhere in guest memory,
> but I didn't think that was your proposal.
hypercall parameter by address pointing to any place in guest has
problem for both solution. That is why we suggest to point to hypercall
shared page. Can this be done by global VHPT?
> 
>>      This is not a big cake. If the domain get more
>> memories(exceed some threshold), it is ok to increase VHPT
>> size dynamically.
> 
> If the per-domain VHPT must be contiguous in physical memory,
> this IS a big cake.
No machine contiguous requirement. The design is using TC map for VHPT,
but stage 1 code use contiguous.

>> this. The VHPT miss will handle this. So don't worry for
>> this. If digging into much details of vMMU, an HV TLB/VHPT is
>> a must to support PMT (guest physical to machine physical).
>> (Oh, you may argu IA64 don't need PMT, if this is the case,
>> it deviates from X86 much more).
> 
> The current implementation does support guest physical to
> machine physical translation.  But the translations are
> put in the TLB and NOT into the VHPT.  If there is a TLB
> miss on a guest physical address, resolving it is slow
> (requiring a multi-level page table lookup),
> but since physical addressing is used relatively infrequently
> (and of course never used by applications), I suspect locality
> is so low that putting guest physical addresses into the
> VHPT won't help much.
> 
> Dan
      I know you are using current IPF linux code (multiple level page
table), but again that deviates from XEN/X86 more.
Any strong reason to deviate?
        In general, I suggest we keep same with XEN/X86 except it is
architectural difference.
Eddie

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel