Re: [Xen-devel] [v3 03/15] Add cmpxchg16b support for x86-64

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.07.15 at 10:33, <feng.wu@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Wednesday, July 08, 2015 4:13 PM
>> >>> On 08.07.15 at 09:06, <feng.wu@xxxxxxxxx> wrote:
>> >> From: xen-devel-bounces@xxxxxxxxxxxxx 
>> >> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Andrew Cooper
>> >> Sent: Thursday, June 25, 2015 2:35 AM
>> >> On 24/06/15 06:18, Feng Wu wrote:
>> >> > +{
>> >> > +    uint128_t prev;
>> >> > +
>> >> > +    ASSERT(cpu_has_cx16);
>> >>
>> >> Given that if this assertion were to fail, cmpxchg16b would fail with
>> >> #UD, I would hand-code a asm_fixup section which in turn panics.  This
>> >> avoids a situation where non-debug builds could die with an unqualified
>> >> #UD exception.
>> >
>> > Is there an existing way to panic the hypervisor in assembler code, I
>> > don't find it, it would be appreciated if you can point it out.
>> 
>> I'm not convinced such a #UD would be a significant problem: Looking
>> at the disassembly will show the cause right away. The out of line
>> ud2-s in some of VMX'es inline assembly wrappers are far worse.
> 
> So, do you agree with the fixup section or not?

I'd rather not go that route, unless Andrew or your manage to
convince me otherwise.

>> I think Andrew's "enforce"
>> really means ASSERT() or BUG_ON(), again to avoid an unqualified
>> exception. However - see above.
>> 
>> Plus, all that said, without having seen the actual use sites of
>> cmpxchg16b yet, I'm not at all convinced we really need this patch.
> 
> After introducing posted format in IRTE, some fields exist in both the
> High 64 bit and the low 64 bit,such as pda_h and pda_l, how to make
> sure it is atomic when updating the pda field?

Is there a need for updating these _after_ initially setting up an
entry?

Jan


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