[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xc_hvm_inject_trap() races
On 11/08/2016 11:19 AM, Razvan Cojocaru wrote: > On 11/08/2016 10:15 AM, Jan Beulich wrote: >>>>> On 07.11.16 at 18:01, <rcojocaru@xxxxxxxxxxxxxxx> wrote: >>> On 11/07/2016 06:10 PM, Jan Beulich wrote: >>>>>>> On 07.11.16 at 16:24, <rcojocaru@xxxxxxxxxxxxxxx> wrote: >>>>> The one-shot vm_event does sound reasonable. I could set a flag >>>>> per-VCPU, basically similar to v->arch.hvm_vcpu.inject_trap.vector, and >>>>> fire a single event from hvm_inject_trap() if it's set (then unset it) - >>>>> the flag would be set via an xc_monitor_next_interrupt() call in libxc. >>>> >>>> Doing this in hvm_inject_trap() would not cover all cases afict. >>>> I'd suggest doing this from hvm_do_resume() _after_ the >>>> (conditional) call to hvm_inject_trap(), if there is _any_ event >>>> pending. >>> >>> But that would only cover the hypercall-injected traps. The condition in >>> hvm_do_resume() is "if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )", >>> and inject_trap.vector seems to only ever be set by the hypercall: >>> [...] >>> So if the next interrupt is not caused by the hypercall, we'll never get >>> another event. Am I reading the code wrong? >> >> No, maybe I expressed myself ambiguously: I meant to say that the >> event should be delivered from hvm_do_resume(), but _outside_ the >> conditional guarding the call to hvm_inject_trap(). Otherwise things >> would have been worse than when doing it inside hvm_inject_trap(). > > While working on this patch, I've had a new idea, which would require > less changes and fix the problem in a more elegant manner if validated. > Looking at vmx_idtv_reinject(), the real problem seems to be that > VM_ENTRY_INTR_INFO is being written to directly: > > 3229 static void vmx_idtv_reinject(unsigned long idtv_info) > 3230 { > 3231 > 3232 /* Event delivery caused this intercept? Queue for redelivery. */ > 3233 if ( unlikely(idtv_info & INTR_INFO_VALID_MASK) ) > 3234 { > 3235 if ( hvm_event_needs_reinjection(MASK_EXTR(idtv_info, > 3236 > INTR_INFO_INTR_TYPE_MASK), > 3237 idtv_info & > INTR_INFO_VECTOR_MASK) ) > 3238 { > 3239 /* See SDM 3B 25.7.1.1 and .2 for info about masking > resvd bits. */ > 3240 __vmwrite(VM_ENTRY_INTR_INFO, > 3241 idtv_info & ~INTR_INFO_RESVD_BITS_MASK); > 3242 if ( idtv_info & INTR_INFO_DELIVER_CODE_MASK ) > 3243 { > 3244 unsigned long ec; > 3245 > 3246 __vmread(IDT_VECTORING_ERROR_CODE, &ec); > 3247 __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, ec); > 3248 } > 3249 } > 3250 > 3251 /* > 3252 * Clear NMI-blocking interruptibility info if an NMI > delivery faulted. > 3253 * Re-delivery will re-set it (see SDM 3B 25.7.1.2). > 3254 */ > 3255 if ( cpu_has_vmx_vnmi && > 3256 ((idtv_info & INTR_INFO_INTR_TYPE_MASK) == > 3257 MASK_INSR(X86_EVENTTYPE_NMI, INTR_INFO_INTR_TYPE_MASK)) ) > 3258 { > 3259 unsigned long intr_info; > 3260 > 3261 __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_info); > 3262 __vmwrite(GUEST_INTERRUPTIBILITY_INFO, > 3263 intr_info & ~VMX_INTR_SHADOW_NMI); > 3264 } > 3265 } > 3266 } > > where the hypercall looks at v->arch.hvm_vcpu.inject_trap.vector only. > Then we notice that the hypercall _fails_immediately_ with -EBUSY if > v->arch.hvm_vcpu.inject_trap.vector is already set: > > 5922 case HVMOP_inject_trap: > 5923 { > 5924 xen_hvm_inject_trap_t tr; > 5925 struct domain *d; > 5926 struct vcpu *v; > 5927 > 5928 if ( copy_from_guest(&tr, arg, 1 ) ) > 5929 return -EFAULT; > 5930 > 5931 rc = rcu_lock_remote_domain_by_id(tr.domid, &d); > 5932 if ( rc != 0 ) > 5933 return rc; > 5934 > 5935 rc = -EINVAL; > 5936 if ( !is_hvm_domain(d) ) > 5937 goto injtrap_fail; > 5938 > 5939 rc = xsm_hvm_control(XSM_DM_PRIV, d, op); > 5940 if ( rc ) > 5941 goto injtrap_fail; > 5942 > 5943 rc = -ENOENT; > 5944 if ( tr.vcpuid >= d->max_vcpus || (v = d->vcpu[tr.vcpuid]) > == NULL ) > 5945 goto injtrap_fail; > 5946 > 5947 if ( v->arch.hvm_vcpu.inject_trap.vector != -1 ) > 5948 rc = -EBUSY; Actually the fix should be even simpler than that: we can add to this if " || hvm_event_pending(v)". Objections? Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |