[Xen-ia64-devel] RE: [Patch] Add uaccess utility for VTI

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>Will do.
>
>But don't you need to use some kind of lock?
>E.g. what happens if the machine address changes
>(due to migration or ballooning or ...) between the
>call to __domain_va_to_ma and the use of the ma?

Thanks for remind. This is one point we definitely need to consider when
designing Guest SMP. But let's do it later ;-)

>
>Also, why is Xen/ia64-VTI different?  Linux/x86,
>Linux/ia64, Xen/x86(non-VTx), Xen/ia64(non-VTi),
>and (I think) Xen/x86-VTx all just do the access
>and manage misses as an exception.  Your approach
>is better if the mapping is missing more often
>than it is present, but how often will this be
>true?
>
>Thanks,
>Dan

I like the idea of poor man's policy, however it doesn't apply to
XEN/VTI.

Linux/x86 can achieve that because user space and kernel space are not
overlapped, but covered by same page table pointed by CR3.

Linux/ia64 can achieve that because user space and kernel space occupies
different regions. When kernel accesses region 0 - 4, mappings in TLB
and VHPT still take effect due to rid unchanged.

Xen/x86(non-VTx) achieves that by similar means, with Xen residing in
upper 64M and domain occupying the rest. One page table already covers
both.

Xen/x86(VTx) resides in different address space as domain, yes,
different page tables with necessary CR3 switch. Following this concept,
it's unlikely for Xen to access virtual address in domain context
directly. Only means is to allocate a range in Xen's space to map gpfn
first, and then access new Xen's va. This is implemented in shadow code
to access guest page table. Also Xiaofeng provides a similar
copy_from_guest when VBD is used in VTx Domain N.

Then saying XEN/ia64(non-VTI), that policy still works since currently
Xen resides with same rid as guest region 7, which makes some TLB
entries still alive for direct access.

OK, now back to XEN/ia64(VTI), we implement Xen in different address
space as Xen/x86(VTx). That means, Xen resides with different rid as
guest, which makes all guest TLB entries useless for direct access then.
The only way is to search vTLB and then use __va() style to access if
hit. That's why you see our version of copy_from/to_user not like its
initial intent.

People may want to know why we adopt different address space, and I'll
explain in another thread to make this long mail not longer. One early
sentence is that policy is not specific to VTI requirement, but can be a
common decision. ;=)

Thanks,
Kevin

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