Re: [Xen-devel] [PATCH v6 3/6] xen/arm: vgic-v2: Don't ignore a write in ITARGETSR if one field is 0

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-11-18 at 16:42 +0000, Julien Grall wrote:
> The current implementation ignores the whole write if one of the field is
> 0. Although, based on the spec (4.3.12 IHI 0048B.b), 0 is a valid value
> when:
> ÂÂÂÂ- The interrupt is not wired in the distributor. From the Xen
> ÂÂÂÂpoint of view, it means that the corresponding bit is not set in
> ÂÂÂÂd->arch.vgic.allocated_irqs.
> ÂÂÂÂ- The user wants to disable the IRQ forwarding in the distributor.
> ÂÂÂÂI.e the IRQ stays pending in the distributor and never received by
> ÂÂÂÂthe guest.
> 
> Implementing the later will require more work in Xen because we always
> assume the interrupt is forwarded to a valid vCPU. So for now, ignore
> any field where the value is 0.
> 
> The emulation of the write access of ITARGETSR has been reworked and
> moved to a new function because it would have been difficult to
> implement properly the behavior with the current code.
> 
> The new implementation is breaking the register in 4 distinct bytes. For
> each byte, it will check the validity of the target list, find the new
> target, migrate the interrupt and store the value if necessary.
> 
> In the new implementation there is nearly no distinction of the access
> size to avoid having too many different path which is harder to test.
> 
> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>

Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

> ---
> ÂÂÂÂThis change used to be embedded in "xen/arm: vgic: Optimize the way
> ÂÂÂÂto store the target vCPU in the rank". It has been moved out to
> ÂÂÂÂavoid having too much functional changes in a single patch.
> 
> ÂÂÂÂI'm not sure if this patch should be backported to Xen 4.6. Without
> ÂÂÂÂit any guest writing 0 in one the field won't be able to migrate
> ÂÂÂÂother interrupts. Although, in all the use case I've seen, the guest
> ÂÂÂÂis read ITARGETSR first and write-back the value with the
> ÂÂÂÂcorresponding byte changed.

Lets park it until someone reports they are tripping over this then.


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