On 04/24/2012 12:54 PM, Xiao Guangrong wrote:
> On 04/24/2012 05:19 PM, Avi Kivity wrote:
>
>
> >>> Turned out to be simpler than expected. However, I think there's a
> >>> problem
> >>> with make_all_cpus_request() possible reading an incorrect vcpu->cpu.
> >>
> >>
> >> It seems possible.
> >>
> >> Can we fix it by reading vcpu->cpu when the vcpu is in GUEST_MODE or
> >> EXITING_GUEST_MODE (IIRC, in these modes, interrupt is disabled)?
> >>
> >> Like:
> >>
> >> if (kvm_vcpu_exiting_guest_mode(vcpu) != OUTSIDE_GUEST_MODE)
> >> cpumask_set_cpu(vcpu->cpu, cpus);
> >
> > I think it is actually okay. We are only vulnerable if lockless shadow
> > walk started during prepare_zap_page(), and extends past
> > kvm_flush_remote_tlbs(), yes? But in that case, vcpu->cpu is stable
> > since local_irq_disable() kills preemption.
> >
>
>
> This case can happen?
>
> VCPU 0 VCPU 1
>
> kvm_for_each_vcpu(i, vcpu, kvm) {
> kvm_make_request(req, vcpu);
>
> VCPU1 is running on CPU 1
> out of guest mode
>
> cpu = vcpu->cpu;
>
> /* Set ->requests bit before we read ->mode */
> smp_mb();
>
> if (cpus != NULL && cpu != -1 && cpu != me &&
>
> VCPU1 is scheduled to CPU 2,
> and running in
> guest mode
>
> kvm_vcpu_exiting_guest_mode(vcpu) != OUTSIDE_GUEST_MODE)
> cpumask_set_cpu(cpu, cpus);
> }
>
> VCPU 0 send IPI to CPU1, but actually, VCPU1 is running on CPU 2.
>
It can happen, but it's benign. After migration, vcpu1 will examine
vcpu->requests and flush the TLB.
--
error compiling committee.c: too many arguments to function
--
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
