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

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

>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins)
>[mailto:dan.magenheimer@xxxxxx]
>Sent: Wednesday, June 22, 2005 12:28 PM
>
>> 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.
>
>So Xen/ia64(VTI) uses eight different region registers?  I
>assume the hardware automatically switches the region registers
>at vm_entry and vm_exit (much like bank0/bank1 r16-r31 are switched)?
>Is it possible to tell the hardware to NOT switch rr0-rr6?
>
>Thanks,
>Dan

Which region register needs to be switched is decided completely by
software. So, yes, this is one area we can think more. Though currently
Xen/VTI only resides in region 7, we don't want eliminate possibility to
use other regions. Like region 5 will be used as resource for virtually
continuous/physical incontiguous allocation later. So we will still
save/restore region 5, 6, 7. Ideally other rids still keep same as in
domain after switch. Then direct access to these regions is possible.

However, in most cases, most buffers that Xen needs to copy_from/to come
from kernel space (region 5-7) of guest Linux (Mainly say hypercall).
That just overlapped with Xen. Based on this assumption, there's no need
to trigger another fault since we know it seldom succeeds in most cases.

Later if that assumption doesn't hold true, we may consider introducing
more complexity to speed up. But until now, keeping current simple flow
seems more preferable.

Thanks,
Kevin

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