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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.10.12 at 16:35, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> 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)?

To answer this last question of yours - I think we're safe, not the
least because no optimization is currently being done to the
(more fragile?) HVM entry points (and the TRAP_regs_* flags
are chosen so that by default any frame that gets created without
knowledge of these flags will be in proper state - "partial" and
"dirty" off (and "dirty" being set on exit is meaningless to code
restoring all registers anyway).

But as always - should it turn out I'm wrong with that assessment,
we should favor reverting these two patches over trying to fix
them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel