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.gr...@citrix.com>
Acked-by: Ian Campbell <ian.campb...@citrix.com> > --- > 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@lists.xen.org http://lists.xen.org/xen-devel
