This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-ia64-devel] One unstablity in fast syscall path
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Wed, 14 Jun 2006 12:02:13 +0900
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>, Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Delivery-date: Tue, 13 Jun 2006 20:02:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD5BC58A4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200606130954.57133.Tristan.Gingold@xxxxxxxx> <516F50407E01324991DD6D07B0531AD5BC58A4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/
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.


Xen-ia64-devel mailing list