From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [v3 03/15] Add cmpxchg16b support for x86-64 Date: Wed, 08 Jul 2015 09:43:50 +0100 Message-ID: <559CFEE6020000780008DFC6@mail.emea.novell.com> References: <1435123109-10481-1-git-send-email-feng.wu@intel.com> <1435123109-10481-4-git-send-email-feng.wu@intel.com> <558AF859.5020107@citrix.com> <559CF78F020000780008DF71@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Feng Wu Cc: Kevin Tian , "keir@xen.org" , "george.dunlap@eu.citrix.com" , Andrew Cooper , "xen-devel@lists.xen.org" , Yang Z Zhang List-Id: xen-devel@lists.xenproject.org >>> On 08.07.15 at 10:33, wrote: >> From: Jan Beulich [mailto:JBeulich@suse.com] >> Sent: Wednesday, July 08, 2015 4:13 PM >> >>> On 08.07.15 at 09:06, wrote: >> >> From: xen-devel-bounces@lists.xen.org >> >> [mailto:xen-devel-bounces@lists.xen.org] 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