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>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] One unstablity in fast syscall path
From: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Date: Wed, 14 Jun 2006 10:13:10 +0200
Delivery-date: Wed, 14 Jun 2006 01:08: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: <516F50407E01324991DD6D07B0531AD5BC58A4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
Le Mardi 13 Juin 2006 22:11, Magenheimer, Dan (HP Labs Fort Collins) a écrit :
> > After reading some Xen/ia64 source, I think we'd better not
> > to use vpsr.ic for
> > fast hypercall: it has some interractions with vpsr.ic flag!
> >
> > I'd vote for creating a new paravirtualized register: xen_break (or
> > xen_hyperprivop): when this new register is set, breaks are
> > hyperprivop, when
> > not set breaks are reflected.
> The advantage of using vpsr.ic is that the vast majority of
> hyperprivops (dynamically) are in the ivt where vpsr.ic is
> already off.  Using a different virtual register requires
> the new virtual register to be set and cleared around the
> use of each hyperprivop (or each group of hyperprivops).
While I was updating Linux entry.S and ivt.S, I didn't have this *feeling*.
However you may be right and in any case this is a real point.

> >B. introduce new flag for hyperprivop instread VPSR.ic as Tristan
> >proposed.
> See above.  English expression: Don't throw out the baby with
> the bath water.
[We have the same expression in French :-)

>  Meaning, just because hyperprivops can't be
> used in every situation doesn't mean they should be rewritten
> so that they can.  I'll bet this suggestion will have a measurable
> negative impact on performance; changing vDSO to use a hypercall
> rather than a hyperprivop may not have any negative impact.
Just a suggestion: you may like to add a new flag.
breaks will be hyperprivop if either VPSR.ic is clear or this flag is set.
However I think this solution must not be the first one.

> E. use hyperprivops for vDSO but via a function call
> to code in hypercall.S (which *is* pinned).
Clean an elegant.
My first choice!


Xen-ia64-devel mailing list