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

Re: [Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write



>>> On 04.05.18 at 05:53, <luwei.kang@xxxxxxxxx> wrote:
>> >      Thanks for your clarification. Please correct me if I have
>> > something wrong. Guest may execute an instruction and this instruction
>> > may produce an PT packet save in PT output buffer. An EPT violation
>> > will be generated if the address of this PT buffer don't have EPT page
>> > table mapping, but this EPT violations shouldn't be handled by
>> > x86_emulate() because it no relate with the execute of this instruction.
>> 
>> Plus - and that's very important - the EPT violation may be reported on some 
> later insn.
> 
> You mean the "later instruction" is some new instruction in future hardware? 

No, I mean an instruction following later in the instruction stream.

>> >      In that case, can we build the EPT map when set the output buffer
>> > address (IA32_RTIT_OUTPUT_BASE) and crash the guest if still happened
>> > EPT violation with Intel PT output buffer read/write exit
>> > qualification. Or add an exit qualification check before instruction 
>> > emulation?
>> 
>> Imo you should add an exit qualification check in any case. Depending what 
> else you do, finding the new bit set may imply crashing
>> the domain or doing something more sophisticated.
> 
> Do you mean add this check at the beginning of any specific "exit_reason" 
> handler in vmx_vmexit_handler() function?

That depends. Surely not for every exit reason, but only those for which this
new bit is valid (iirc exit qualifications differ per exit reason anyway, so you
can't unilaterally check the same bit everywhere). And even for those where
the bit is valid, I'm not sure you can decide in the exit handler alone what to
do if the bit is set. It may be necessary to propagate the flag down the call
tree.

> Another question is where to build this EPT mapping? Setting 
> IA32_RTIT_OUTPUT_BASE or handled by EPT violation?

I have no idea - that's more a question for you to answer yourself.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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