Re: [Xen-devel] [PATCH v3 7/9] xen/arm: vgic: Optimize the way to store the target vCPU in the rank

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-10-08 at 12:36 +0100, Stefano Stabellini wrote:
> On Thu, 8 Oct 2015, Ian Campbell wrote:
> > On Wed, 2015-10-07 at 19:16 +0100, Julien Grall wrote:
> > 
> > > Furthermore, based on the spec (4.3.12 in IHI 0048B.b): "A register
> > > field corresponding to an unimplemented interrupt is RAZ/WI."
> > > 
> > > If the user knows that an interrupt is not implemented, he may decide
> > > to
> > > write 0 in the corresponding byte. With the current solution, the
> > > whole
> > > write access is ignored.
> > > 
> > > The solution suggested in this patch is less restrictive and will
> > > just
> > > ignore the corresponding byte if it's 0.
> > 
> > I think this (a 32-bit register covering both implemented and non
> > -implemented interrupts) is a compelling reason to only ignore the
> > specific
> > zero bytes and not the whole word.
> 
> I agree that zero writes to unimplemented interrupts should be allowed.
> However allowing them for everything encourages 32-bit writes with just
> one byte set, the one that the OS actually wants to write. It doesn't
> seem correct to me. Something like:
> 
> uint32_t val = 0x2 << 8;
> write32(ITARGETSR + something, val);
> 
> which I don't think is supposed to work. That said, I recognize that
> this is a minor issue, so I won't insist.

Right.

The underlying issue here is that we can't cope with interrupts which are
not routed to any CPU at all, which is the expected semantics for a write
of 0 to the TARGET, right? (such interrupts essentially remain pending in
the distributor).

How hard would it be to actually implement that and therefore avoid this
whole issue?

Another approach btw would be to insist that nr_spis was a multiple of at
least 4, then you don't have registers which are a mixture of implemented
and unimplemented, which might simplify the logic.

Ian.

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