From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 3/3] x86: save/restore only partial register state where possible Date: Wed, 03 Oct 2012 15:35:27 +0100 Message-ID: References: <506C461E020000780008D00F@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <506C461E020000780008D00F@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/10/2012 14:05, "Jan Beulich" wrote: >>>> Keir Fraser 10/02/12 7:02 PM >>> >> On 02/10/2012 16:27, "Jan Beulich" 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 >> >> 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 >