| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] One unstablity in fast syscall path
> 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).
> Of course, changing the logic requires some work and careful checks.
Yes, be very careful in changing this code... I spent weeks
debugging these few hundred lines of assembly. And since
it would change the API between Xen and Xenlinux, it will
be difficult to phase the change in.
>There are the following choices for right fix, I think.
>
>A. use hypercall instead of hyperprivop.
For vDSO only? How frequently is this used? The difference
might be negligible.
The hyperprivop interface has a specific usage -- make high
frequency operations run very fast -- and many constraints
(such as don't use in code that isn't pinned by a vTR, don't
use in code where interrupts can't be turned off). These
constraints should admittedly be documented.
>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. 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.
>C. use one of itr to map vDSO.
Seems like a waste of a precious resource.
>D. abondan vDSO paravirtualization.
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.
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).
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home