From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [v3 03/15] Add cmpxchg16b support for x86-64 Date: Wed, 08 Jul 2015 09:50:42 +0100 Message-ID: <559CE462.5040503@citrix.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: <559CF78F020000780008DF71@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Feng Wu Cc: "george.dunlap@eu.citrix.com" , YangZ Zhang , Kevin Tian , "keir@xen.org" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 08/07/2015 09:12, Jan Beulich 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. When I asked for this, I was thinking of having an assertion frame with the cmpxchg16b instruction in the place of the regular ud2a. This way, if it were to failed with #UD, there is a more useful error message. However, there is no easy way of doing this at the moment, and it is an obscure set of circumstances, so probably not worth the hassle. > 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. Unqualified #UDs are harder to debug than qualified ones, and I have an annoying habit of hitting them. In some copious free time, I want to continue the work started with c/s 0a3e27e and 881d6bf. git grep suggests there isn't actually too much to fix up in this regard. ~Andrew