[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-ia64-devel] One unstablity in fast syscall path
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
> 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