On 9/14/23 18:46, andrew.cooper3@xxxxxxxxxx wrote:
On 15/09/2023 1:38 am, H. Peter Anvin wrote:
On 9/14/23 17:33, andrew.cooper3@xxxxxxxxxx wrote:
It's an assumption about what "definitely won't" be paravirt in the
future.
XenPV stack handling is almost-FRED-like and has been for the better
part of two decades.
You frequently complain that there's too much black magic holding XenPV
together. A paravirt-FRED will reduce the differences vs native
substantially.
Call it "paravirtualized exception handling." In that sense, the
refactoring of the exception handling to benefit FRED is definitely
useful for reducing paravirtualization. The FRED-specific code is
largely trivial, and presumably what you would do is to replace the
FRED wrapper with a Xen wrapper and call the common handler routines.
Why do only half the job?
There's no need for any Xen wrappers at all when XenPV can use the
native FRED paths, as long as ERETU, ERETS and the relevant MSRs can be
paravirt (sure - with an interface that sucks less than right now) so
they're not taking the #GP/emulate in Xen path.
And this can work on all hardware with a slightly-future version of Xen
and Linux, because it's just a minor adjustment to how Xen writes the
exception frame on the guests stack as part of event delivery.
It's not about doing "half the job", it's about using the proper
abstraction mechanism. By all means, if you can join the common code
flow earlier, do so, but paravirtualizing the entry/exit stubs which is
the *only* place ERETU and ERETS show up is just crazy.
Similarly, nearly all the MSRs are just configuration setup. The only
ones which have any kind of performance relevance is the stack setup (RSP0).
-hpa
