On 22/06/16 17:26, Marc Zyngier wrote: > On 17/06/16 13:08, Andre Przywara wrote: >> LPIs are dynamically created (mapped) at guest runtime and their >> actual number can be quite high, but is mostly assigned using a very >> sparse allocation scheme. So arrays are not an ideal data structure >> to hold the information. >> We use an RCU protected list to hold all mapped LPIs. vgic_its_get_lpi() >> iterates the list using RCU list primitives, so it's safe to be called >> from an non-preemptible context like the KVM exit/entry path. >> Also we store a pointer to that struct vgic_irq in our struct its_itte, >> so we can easily access it. >> Eventually we call our new vgic_its_get_lpi() from vgic_get_irq(), so >> the VGIC code gets transparently access to LPIs. >> >> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx> > > I'm skipping the review of this particular patch until you've switched > to the kref API. As an added comment, and having gone through this and the following patches, I cannot see what having an RCU list brings us if we're also using refcounting. Taking a spinlock on the read side feels very dodgy (what guarantees that we can make forward progress without messing with the grace period?), and I feel that we need to keep things relatively simple. Not simplistic, but slightly simpler. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
