Re: [Xen-ia64-devel] One unstablity in fast syscall path

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

On Tue, Jun 13, 2006 at 01:11:04PM -0700, Magenheimer, Dan (HP Labs Fort 
Collins) wrote:

> There are two purposes of paravirtualization: one is correctness
> and the other is performance.  If "fully virtualized" vDSO
> works properly and there's no impact on performance, it
> shouldn't be paravirtualized.  If there is a measurable
> impact, it should be paravirtualized.

I fully agree with you that paravirtualization for performance
must be backed by a sort of measurement.


I have a question on priv_handle_op().
I changed the function so that xen/ia64 reflects itlb miss to a domain
when xen/ia64 fails to read a bundle.
Xen/ia64 reflected dtlb miss before my change.

Is it correct to reflect dtlb miss?
I guess you already encountered the same problem
and gave the consideration on it.

With my change, the following sequence happens on every system call entry.
It would causes performance loss. So I thought it was worthwhile to
paravirtualize vDSO area.

1. a domain enters to vDSO
2. execute privilieged op. (rsm or reading psr)
3. traps to Xen/IA64
4. Xen/IA64 tries to read the operation, but fails because
   the vDSO page is only mapped by itlb cache.
   (This depends on processor tlb cache implementation)
   So it reflects itlb.
5. a domain issued itlb insert and xen/ia64 cached vcpu->arch.itlb
6. a domain re-execute the privileged op.
7. traps to Xen/IA64
8. Xen/IA64 successes to read the op with vcpu->arch.itlb
   and emulates the op.


> If I understand the problem (not sure I do fully), there is:
> 
> E. use hyperprivops for vDSO but via a function call
> to code in hypercall.S (which *is* pinned).

This options sounds good.

Thanks.
-- 
yamahata

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