On Wed, Jul 28, 2010 at 02:04:35PM -0400, Avi Kivity wrote:
> On 07/28/2010 07:25 PM, Avi Kivity wrote:
> >
> > +static void corrupt_cr3_intercept_bypass(void *_test)
> > +{
> > + struct test *test = _test;
> > + extern volatile u32 mmio_insn;
> > +
> > + while (!__sync_bool_compare_and_swap(&test->scratch, 1, 2))
> > + pause();
> > + pause();
> > + pause();
> > + pause();
> > + mmio_insn = 0x90d8200f; // mov %cr3, %rax; nop
> > +}
> > +
> > +static void prepare_cr3_intercept_bypass(struct test *test)
> > +{
> > + default_prepare(test);
> > + test->vmcb->control.intercept_cr_read |= 1<< 3;
> > + on_cpu_async(1, corrupt_cr3_intercept_bypass, test);
> > +}
> > +
> > +static void test_cr3_intercept_bypass(struct test *test)
> > +{
> > + ulong a = 0xa0000;
> > +
> > + test->scratch = 1;
> > + while (test->scratch != 2)
> > + barrier();
> > +
> > + asm volatile ("mmio_insn: mov %0, (%0); nop"
> > + : "+a"(a) : : "memory");
> > + test->scratch = a;
> > +}
>
> ftrace makes it quite easy to see how things go wrong:
>
> > qemu-system-x86-10545 [004] 98291.582062: kvm_exit: reason vmrun rip
> > 0x4003d4
>
> step into the guest
>
> > qemu-system-x86-10546 [006] 98291.582064: kvm_inj_virq: irq 32
>
> here's out evil IPI
>
> > qemu-system-x86-10545 [004] 98291.582064: kvm_nested_vmrun: rip:
> > 0x00000000004003d1 vmcb: 0x0000000007ff8000 nrip: 0x0000000000400330
> > int_ctl: 0x00000000 event_inj: 0x00000000 npt: off
> > qemu-system-x86-10546 [006] 98291.582065: kvm_inj_virq: irq 32
> > qemu-system-x86-10545 [004] 98291.582065: kvm_nested_intercepts:
> > cr_read: 0008 cr_write: 0000 excp: 00000000 intercept: 0000000300000000
>
> Note cr3 reads are intercepted
>
> > qemu-system-x86-10546 [006] 98291.582065: kvm_entry: vcpu 1
> > qemu-system-x86-10545 [004] 98291.582070: kvm_entry: vcpu 0
> > qemu-system-x86-10545 [004] 98291.582072: kvm_exit: reason npf rip
> > 0x400368
> > qemu-system-x86-10545 [004] 98291.582073: kvm_nested_vmexit: rip:
> > 0x0000000000400368 reason: npf ext_inf1: 0x0000000000000006 ext_inf2:
> > 0x00000000000a0000 ext_int: 0x00000000 ext_int_err: 0x00000000
>
> access assigned mmio -> trap to host
>
> > qemu-system-x86-10546 [006] 98291.582074: kvm_exit: reason npf rip
> > 0x4013c9
> > qemu-system-x86-10545 [004] 98291.582074: kvm_page_fault: address
> > a0000 error_code 6
> > qemu-system-x86-10546 [006] 98291.582074: kvm_page_fault: address
> > fee000b0 error_code 6
>
> IPI on its way out
>
> > qemu-system-x86-10545 [004] 98291.582075: kvm_emulate_insn: 0:400368:
> > 0f 20 d8 (prot64)
>
> Emulating mov %cr3, %rax
Yeah, its the failure case we discussed yesterday. Another question, is
there any way to run these tests bare-metal to verify them first on real
silicon? This would be very helpful to have the proof that a test really
works, especially in the nested-svm case.
The dependency on the testdev seem to make things difficult. But I
havn't investigated this further yet.
Joerg
--
Joerg Roedel - AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
