Re: [Xen-devel] Future x86 emulator direction

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/12/16 08:53, Razvan Cojocaru wrote:
> On 12/13/2016 07:10 PM, Andrew Cooper wrote:
>> On 13/12/16 15:58, Razvan Cojocaru wrote:
>>> Hello, and first of all thanks for the discussion!
>>>
>>>> Think of it a bit more like introducing a new action emulator (name
>>>> definitely subject to improvement), which implements things such as
>>>> wrmsr, cpuid, pagewalk, task_switch, etc.
>>>>
>>>> The vmexit helpers, given decode assistance from hardware, can directly
>>>> call action->task_switch().  If insufficient information is available
>>>> (e.g. LMSW on AMD), the helpers invoke the instruction emulator to work
>>>> out what to do, and the instruction emulator would invoke the action
>>>> emulator as part of its execute phase.
>>>>
>>>> Wherever possible, the action emulator should be guest-neutral, and
>>>> ideally the single point of implementation of non-architectural actions
>>>> such as "the vm_event subsystem is interested in this."
>>>>
>>>>> And to be honest, on the road towards
>>>>> completion of the emulator I think the SVM/VMX insns are pretty
>>>>> close to the end of the priority list.
>>>> I'd expect them to show up frequently during introspection, although
>>>> maybe I am wrong.  Razvan: Any thoughts?
>>> I definitely think this is a good idea as far as introspection goes -
>>> having a single contact surface with the underlying logic would be a
>>> significant improvement.
>>>
>>> As for SVM/VMX instructions, we're interested in anything that is able
>>> to trigger an EPT fault (and hence a mem_access event) - we've had our
>>> share of adventures with VMX-specific instructions, so they're not low
>>> priority for us.
>> In reality, this is any instruction if you set EPT NX on a page, I presume?
>>
>> Do you have stats on which instructions you most frequently have to
>> singlestep because of lack of emulator support, or is the spread
>> essentially random?
> Here's what I've gathered just now with nothing more than just starting
> up, firing up Internet Explorer and Firefox, and shutting down a few
> Windows 7 (32 and 64 bit) guests:
>
> 64-bit guest 1:
>
> (XEN) Mem event emulation failed: d1v0 32bit @ 0023:7489f1f8 -> 66 0f 12
> 44 24 04 ba 00 00 00 00 66 0f 28 e8 66

movlpd 0x4(%rsp),%xmm0

>
> 64-bit guest 2:
>
> (XEN) Mem event emulation failed: d2v1 32bit @ 0023:734cf031 -> 66 0f ef
> c0 51 53 8b c1 83 e0 0f 85 c0 75 7f 8b

pxor   %xmm0,%xmm0

>
> 32-bit guest:
>
> (XEN) Mem event emulation failed: d3v0 32bit @ 001b:7359f1f8 -> 66 0f 12
> 44 24 04 ba 00 00 00 00 66 0f 28 e8 66

Another movlpd 0x4(%esp),%xmm0

> (XEN) Mem event emulation failed: d3v0 32bit @ 001b:7359e7d5 -> 66 0f 12
> 0d 90 f1 59 73 f2 0f 59 c8 66 0f 12 15

movlpd 0x7359f190,%xmm1

The movlpd's should be easy to implement.  They aren't meaningfully
different from their integer counterparts in terms of needs for the
emulator.

> (XEN) Mem event emulation failed: d3v0 32bit @ 0008:821d385f -> 0f 6e 06
> 0f 72 d0 18 0f ef 05 08 f6 32 82 0f 61

This is just a straight movd (%esi),%mm0

I could have sworn we already had support for this...

~Andrew

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