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

[Keir Fraser <keir.xen@xxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel