[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 04/12] xen/arm: support for guest SGI
On Mon, 2013-04-29 at 18:51 +0100, Stefano Stabellini wrote: > On Mon, 29 Apr 2013, Stefano Stabellini wrote: > > On Mon, 29 Apr 2013, Ian Campbell wrote: > > > On Mon, 2013-04-29 at 16:47 +0100, Stefano Stabellini wrote: > > > > On Mon, 29 Apr 2013, Ian Campbell wrote: > > > > > On Sun, 2013-04-28 at 15:26 +0100, Stefano Stabellini wrote: > > > > > > On Fri, 26 Apr 2013, Ian Campbell wrote: > > > > > > > > + > > > > > > > > + > > > > > > > > + for_each_set_bit( vcpuid, &vcpu_mask, d->max_vcpus ) > > > > > > > > + { > > > > > > > > + if ( vcpuid >= d->max_vcpus || (vt = d->vcpu[vcpuid]) > > > > > > > > == NULL ) > > > > > > > > > > > > > > Is d->vcpu[vcpuid] == NULL sufficient here? A vcpu which exists > > > > > > > but has > > > > > > > not been PSCI'd up will pass this -- what do we do to them? > > > > > > > Hopefully we > > > > > > > don't wake them up? Do we not want to check something like > > > > > > > _VPF_down > > > > > > > too? > > > > > > > > > > > > I think you are right, we should test for _VPF_down too > > > > > > > > > > Are there any interesting races here? Seems like there should be, > > > > > unless > > > > > we hold the domain lock or something? > > > > > > > > > > > > Considering that max_vcpus is static, d->vcpu[vcpuid] has been > > > > allocated at domain creation and that test_bit should be atomic, I don't > > > > think there are any races here. > > > > What am I missing? > > > > > > The race between checking the bit and acting on the result. > > > > I don't think that race can cause any problems: if vcpu0 is sending a > > TARGET_OTHERS SGI and vcpu1 is executing psci.cpu_off, depending on who > > wins the race vcpu1 is going to receive the SGI on not, but the result > > is going to be always consistent: if vcpu1 shuts down before the SGI is > > sent, it is not going to receive it (actually it is going to receive it > > if it gets ever woken up), otherwise it is going to receive it before > > shutting down. Did you test the case where the SGI gets delivered to a CPU which was up but now is down? We don't want to crash because some resource has been freed etc... > That makes me realize that we might not want to queue up interrupts when > a cpu is offline, what do you think? Probably we should either avoid that or explicitly clear the queue when we bring a CPU up. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |