[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible

  • To: Jan Beulich <JBeulich@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxx>
  • Date: Tue, 02 Oct 2012 18:02:31 +0100
  • Delivery-date: Tue, 02 Oct 2012 17:02:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac2gv7Wg1B8+k87pIkqlr4SJ15pQXw==
  • Thread-topic: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible

On 02/10/2012 16:27, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> ... and make restore conditional not only upon having saved the state,
> but also upon whether saved state was actually modified (and register
> values are known to have been preserved).
> Note that RBP is unconditionally considered a volatile register (i.e.
> irrespective of CONFIG_FRAME_POINTER), since the RBP handling would
> become overly complicated due to the need to save/restore it on the
> compat mode hypercall path [6th argument].
> Note further that for compat mode code paths, saving/restoring R8...R15
> is entirely unnecessary - we don't allow those guests to enter 64-bit
> mode, and hence they have no way of seeing these registers' contents
> (and there consequently also is no information leak, except if the
> context saving domctl would be considered such).
> Finally, note that this may not properly deal with gdbstub's needs, yet
> (but if so, I can't really suggest adjustments, as I don't know that
> code).
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Ugly. I'd prefer not to bother unless there really is a win we could care
about here.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.