Re: [Xen-devel] [PATCH v4 04/12] xen/arm: support for guest SGI

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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

That makes me realize that we might not want to queue up interrupts when
a cpu is offline, what do you think?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel