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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.01.18 at 19:12, <luwei.kang@xxxxxxxxx> wrote:
> +int pt_do_wrmsr(unsigned int msr, uint64_t msr_content)
> +{
> +    struct pt_desc *pt_desc = &current->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.

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.
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.

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