Re: [PATCH v2 1/3] x86/pv: Introduce x86_merge_dr6() and fix do_debug()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.08.2024 18:34, Andrew Cooper wrote:
> On 15/08/2024 4:41 pm, Jan Beulich wrote:
>> On 15.08.2024 15:15, Andrew Cooper wrote:
>>> Pretty much everywhere in Xen the logic to update %dr6 when injecting #DB is
>>> buggy.  The architectural behaviour is to overwrite B{0..3} (rather than
>>> accumulate) and accumulate all other bits.
>> Just to double check (after 6 years I clearly don't recall anything that 
>> isn't
>> written down in the description): The SDM pretty vaguely says "Certain debug
>> exceptions may clear bits 0-3." What other information sources are there to
>> make this less uncertain? (Picking an old hardcopy from the shelf, that
>> confirms that long ago DR6 was indeed documented as all sticky.)
> 
> Well, "talking with the architects", but as always "it's complicated".
> 
> The debug infrastructure has had several breaking changes in it over the
> years (e.g. the reserved bits didn't use to be f's), and this one
> probably changed with the introduction of superscalar pipelines.  That
> said, I don't think I've ever found a Spec Update / Revision Guide that
> doesn't have one "oops we don't do breakpoints properly in this case"
> erratum listed.
> 
> I'm informed it's "most going on all exceptions" these days, and the
> behaviour here did come mostly from my discussions about XSA-308 (or
> rather, the pre-security angle where it was just a bugfix) with Intel.
> 
> A guest that does clear the status bits every #DB won't notice, and one
> that doesn't will have problems on real hardware.
> 
> But I can reword if if you'd prefer?

If I may ask, I'd like it to at least be clarified that documentation isn't
quite precise here. Kind of to soften "architectural behaviour" a little.

Jan