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

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

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!

Tristan.

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