[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
> > +int pt_do_wrmsr(unsigned int msr, uint64_t msr_content) { > > + struct pt_desc *pt_desc = ¤t->arch.hvm_vmx.pt_desc; > > + > > + if ( !opt_intel_pt ) > > + return 1; > > + > > + switch ( msr ) { > > + case MSR_IA32_RTIT_CTL: > > + pt_set_rtit_ctl(pt_desc, msr_content); > > + break; > > + case MSR_IA32_RTIT_STATUS: > > + pt_desc->guest_pt_ctx.status = msr_content; > > + break; > > + case MSR_IA32_RTIT_OUTPUT_BASE: > > + pt_desc->guest_pt_ctx.output_base = msr_content; > > + break; > > + case MSR_IA32_RTIT_OUTPUT_MASK: > > + pt_desc->guest_pt_ctx.output_mask = msr_content | 0x7F; > > + break; > > + case MSR_IA32_RTIT_CR3_MATCH: > > + pt_desc->guest_pt_ctx.cr3_match = msr_content; > > + break; > > + default: > > + pt_desc->guest_pt_ctx.addr[msr - MSR_IA32_RTIT_ADDR0_A] = > > + msr_content; > > At least these last ones need to have a canonical address check attached. Get it. Will add address range number check and "goto gp_fault" if access unsupported MSRs. > > And there is one more thing I've not found throughout the series: EPT > violations and a few other VM exits have gained a new > qualification bit, indicating that it's not the current instruction which has > caused the exit. Hi Jan, I don't quite understand here about EPT violations and other VM exit qualification bit. There may have an EPT violations when guest record trace to ToPA. Is this what is your concern? About new vm-exit qualification bit, do you mean there have new qualification bit for Intel PT? > I can't imagine this to not require any change to the handling of such exits > - in particular, such exits must never be handled by > invoking the insn emulator. Aiui the only handling options here are to > eliminate the condition causing the exit, or to crash the guest. > There's no way to emulate the intended access. Emulate which instructions? Can you give me an example? Thanks, Luwei Kang > > Yet another apparently missing piece appears to be the corresponding XSAVE > handling. > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |