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

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, July 08, 2015 4:44 PM
> To: Wu, Feng
> Cc: Andrew Cooper; george.dunlap@xxxxxxxxxxxxx; Tian, Kevin; Zhang, Yang Z;
> xen-devel@xxxxxxxxxxxxx; keir@xxxxxxx
> Subject: RE: [Xen-devel] [v3 03/15] Add cmpxchg16b support for x86-64
> 
> >>> 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?

Each time the guest sets the affinity, we need to change this
filed to refer to the new destination.

Thanks,
Feng

> 
> Jan


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