[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] x86/HVM: re-order operations in hvm_ud_intercept()



On 09/06/16 13:31, Jan Beulich wrote:
>>>> On 09.06.16 at 13:34, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 08/06/16 14:43, Jan Beulich wrote:
>>> Don't fetch CS explicitly, leverage the fact that hvm_emulate_prepare()
>>> already does (and that hvm_virtual_to_linear_addr() doesn't alter it).
>>>
>>> At once increase the length passed to hvm_virtual_to_linear_addr() by
>>> one: There definitely needs to be at least one more opcode byte, and we
>>> can avoid missing a wraparound case this way.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> I looked into this when you suggested it, but it latches the wrong eip
>> in the emulation state, and you will end up re-emulating the ud2a
>> instruction, rather than the following instruction.
> Where is there any latching of eip? All hvm_emulate_prepare() does
> is storing the regs pointer.

Oh - so it does.  I clearly looked over it too quickly.

What wraparound issue are you referring to?  Adding 1 will cause
incorrect behaviour when the emulation prefix ends at the segment limit.

~Andrew

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.