[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] further post-Meltdown-bad-aid performance thoughts
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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |