Re: [Xen-devel] [PATCH 5/5] x86/HVM: cache emulated instruction for retry processing

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2013-12-18:
>>>> On 18.12.13 at 09:36, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2013-09-30:
>>> Rather than re-reading the instruction bytes upon retry processing,
>>> stash away and re-use tha what we already read. That way we can be
>>> certain that the retry won't do something different from what
>>> requested the retry, getting once again closer to real hardware
>>> behavior (where what we use retries for is simply a bus operation, not
>>> involving redundant decoding of instructions).
>>> 
>> 
>> This patch doesn't consider the nested case.
>> For example, if the buffer saved the L2's instruction, then vmexit
>> to
>> L1 and
>> L1 may use the wrong instruction.
> 
> I'm having difficulty seeing how the two could get intermixed: There
> should be, at any given point in time, at most one instruction being
> emulated. Can you please give a more elaborate explanation of the
> situation where you see a (theoretical? practical?) problem?

I saw this issue when booting L1 hyper-v. I added some debug info and saw the 
strange phenomenon: 

(XEN) write to buffer: eip 0xfffff8800430bc80, size 16, content:f7420c1f608488b 
44000000011442c7
(XEN) read from buffer: eip 0xfffff800002f6138, size 16, 
content:f7420c1f608488b 44000000011442c7

From the log, we can see different eip but using the same buffer. Since I don't 
know how hyper-v working, so I cannot give more information why this happens. 
And I only saw it with L1 hyper-v (Xen on Xen and KVM on Xen don't have this 
issue) .

> 
>> There are two ways to fix it, but I am not sure one is better:
>> 
>> one is record instruction eip and check whether the eip is same when
>> reading  from buffer:
>> ...
>> Another one is to clear buffer when virtual vmentry and virtual
>> vmexit
>> happens:
> 
> The former is unsuitable (what if both L1's and L2's instructions
> happen to be on the same address?
> 
> Jan


Best regards,
Yang



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