From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] vmx: Allow software (user defined) interrupts to be injected in to the guest Date: Thu, 03 May 2012 15:35:36 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Dong, Eddie" , Jan Beulich Cc: Aravindh Puthiyaparambil , "Nakajima, Jun" , xen-devel List-Id: xen-devel@lists.xenproject.org On 03/05/2012 14:42, "Dong, Eddie" wrote: >>> The TRAP_debug should not use SW_EXCEPTION, it should use >> HW_EXCEPTION >>> Per SDM and confirmation from our HW guys. We will send fixes soon. >> >> Please also have the opcode 0xF1 generated #DB addressed in >> whatever is the appropriate way. > > Opcode 0xf1 should use " privileged software exception". > > What we can do probably include: > 1: A patch to fix the mistake of #BP & #OF, plus additional comments to state > the usage of the API. > 2: Another patch to provide a new API for 0xf1 & CD nn? But we don't have real > usage case to test so far. Yes, this sounds great. -- Keir > We will provide #1 quickly, but for #2, can Aravindh provide test if we get > the patch ready? > >> >>>> >>>> Anyone except perhaps LOCK - none of them should have any effect >>>> other than making the instruction longer. >>>> >>> LOCK can never be used as prefix of INT nn instruction, nor can REPx >> prefix. >>> Can you provide more details as for this concern? >> >> The only prefix that is documented to cause #UD here is LOCK. All > > In #UD case (fault), the guest RIP is not advanced per SDM, and therefore > guest will either > spin in the previous LOCK instruction, or advance the IP to next instruction > by guest #UD handler. > I didn't see emulator could advance IP to the next instruction (INT nn) for > LOCK prefix. > Do I miss something? > >> other prefixes should consequently be considered ignored, and so >> should the emulation do (and properly handle resulting instruction >> lengths). >> > The behavior is un-defined per SDM in this case, so either solution should be > fine :) > > Thx, Eddie > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel