Re: [Xen-devel] [PATCH for-next 2/3] xen/x86: Introduce static inline wrappers for l{idt, gdt, ldt, tr}()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.10.17 at 18:06, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/10/17 16:53, Jan Beulich wrote:
>>>>> On 02.10.17 at 18:13, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> The triple-fault reboot method stays as is, to avoid the int3 possibly 
>>> getting
>>> moved relative to the lidt.
>> Aren't asm volatile()s ordered wrt to one another?
> 
> From the docs
> 
> "Note that the compiler can move even volatile |asm| instructions
> relative to other code, including across jump instructions."

I had looked at the doc (and this sentence) before replying: It
does not make explicit whether two volatile asm()s can be
legitimately moved. After all the purpose of the volatile is to
deal with resource (register) uses which can't otherwise be
expressed to the compiler. The example they give there with
the floating point control/status register isn't sufficient, as it
doesn't show how an asm() producing and one consuming the
resource would interact.

But yes, to be on the safe side keeping insn here both in one
asm() is certainly the better option.

> Also, I seem to recall Tim finding an example where GCC 6 did reorder
> two asm volatiles relative to each other, due to their output operands
> not being causally linked.

Oh, good to know. In which case using a fake operand would
help to establish a dependency (like suggested in that PPC
example in the doc, albeit partially wrong afaict in that the
asm() writing a variable the subsequent statement also write
does not make this a valid dependency - the asm() would need
to write x or y imo), but of course that wouldn't make things
any better for the specific triple fault case here.

> On that note however, these should gain memory clobbers to make them
> full barriers.  l{i,g}dt() are serialising, while nothing good will come
> of having a segment register access reordered with respect to l{g,l}dt().
>[...]
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Does this still stand in light of the barrier change above?

Sure.

Jan


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