Re: [PATCH] KVM: VMX: Update instruction length on intercepted BP

Jan Kiszka
2010-02-17T11:24:39Z

Gleb Natapov wrote:
> On Wed, Feb 17, 2010 at 01:11:36PM +0200, Avi Kivity wrote:
>> On 02/15/2010 03:30 PM, Gleb Natapov wrote:
>>>> I just did this on our primary AMD platform (Embedded Opteron, 13KS EE),
>>>> and it just worked.
>>>>
>>>> But this is a fairly new processor. Consequently, it reports NextRIP
>>>> support via cpuid function 0x8000000A. Looking for an older one too.
>>>>
>>>> In the meantime I also browsed a bit more in the manuals, and I don't
>>>> think stepping over or (what is actually required) into an INT3 will
>>>> work. We can't step into as the processor clears TF on any event handler
>>>> entry. And stepping over would cause troubles
>>>>
>>>> a) as an unknown amount of code may run without #DB interception
>>>> b) we would fiddle with TF in code that is already under debugger
>>>> control, thus we would very likely run into conflicts.
>>>>
>>>> Leaves us with tricky INT3 emulation. Sigh.
>>>>
>>> So the question is do we want to support this kind of debugging on older
>>> AMDs. May we don't.
>> How much older are they?
>>
> Actually I am not sure new AMDs support this correctly. Need one to run
> tests. GDB is not a good test case, it is too smart.

It works well - and gdb is far from being "smart": one byte off the
expected INT3 address, and everything falls apart. That's what the VMX
bug demonstrated.

Jan

--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux