[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>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Wed, 03 Oct 2012 15:35:27 +0100
  • Cc: xen-devel@xxxxxxxxxxxxx
  • Delivery-date: Wed, 03 Oct 2012 14:35:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac2hdFSG1j75QiymQECiXZbJUV578Q==
  • Thread-topic: [Xen-devel] [PATCH 3/3] x86: save/restore only partial register state where possible

On 03/10/2012 14:05, "Jan Beulich" <jbeulich@xxxxxxxx> wrote:

>>>> Keir Fraser <keir@xxxxxxx> 10/02/12 7:02 PM >>>
>> 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.
> Without this patch, patch 1 doesn't make a lot of sense either (and patch 2
> then is merely cleanup).

Okay, can you re-submit with some comments around what the new TRAP flag
values mean and how they should be used? Maybe some comments for the
save/restore macros, and their new arguments, would be nice too. And are you
confident that this approach is maintainable/non-fragile (i.e., we're not
going to be continually finding rare cases where registers are being dirtied
but not saved/restored)?

 -- Keir

> Jan

Xen-devel mailing list



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