From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] x86_emulate adjustments Date: Fri, 05 Jan 2007 11:25:20 +0000 Message-ID: References: <459E307D.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <459E307D.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 5/1/07 10:03, "Jan Beulich" wrote: > - don't provide cmpxchg8b emulation where not needed (i.e. page table ops on > 64-bit hv) With the cmpxchg16b changes this probably makes sense, despite my dislike of ifdef if it can be avoided. I'll take a look. > - properly deal with stack operands (push/pop) I already got the mis-emulation of x86/64 PUSH/POP with operand-size override. The stacksz thing I would do differently -- extend the mode input field to have an extra stack-address-size field. There's another thing that's not right at the moment -- I think on POP we have to calculate the operand effective address after adjusting the stack pointer? That is broken right now which is not a good thing. :-) > - synchronize prefix handling with hvm's instrlen determination and about to > be committed privileged op decoder (changes coming with the 32on64 patches) The whole lot of hvm_instrlen/mmio/privop emulators are all going to get merged into x86_emulate(). So sync'ing is not really worthwhile, unless there are bugs in x86_emulate()'s prefix decoder. > - support cmpxchg16b if the CPU supports it I'll take a look at this part. Sounds sensible. Thanks, Keir