Re: [Xen-devel] Future x86 emulator direction

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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?

~Andrew

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