further post-Meltdown-bad-aid performance thoughts

["Jan Beulich" <JBeulich@suse.com>]

All,

along the lines of the relatively easy first step submitted yesterday,
I've had some further thoughts in that direction. A fundamental
thing for this is of course to first of all establish what kind of
information we consider safe to expose (in the long run) to guests.

The current state of things is deemed incomplete, yet despite my
earlier inquiries I haven't heard back any concrete example of
information, exposure of which does any harm. While it seems to be
generally believed that large parts of the Xen image should not be
exposed, it's not all that clear to me why that would be. I could
agree with better hiding writable data parts of it, just to be on the
safe side (I'm unaware of statically allocated data though which
might carry any secrets), but what would be the point of hiding
code and r/o data? Anyone wanting to know their contents can
simply obtain the Xen binary for their platform.

Similar considerations apply to the other data we currently keep
mapped while running 64-bit PV guests.

The reason I bring this up is because further steps in the direction
of recovering performance would likely require as a prerequisite
exposure of further data, first and foremost struct vcpu and
struct domain for the currently active vCPU. Once again I'm not
aware of any secrets living there. Another item might need to be
the local CPU's per-CPU data.

Additionally this would require leaving interrupts turned off for
longer periods of time on the entry paths.

Feedback appreciated, thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel