On Fri, Dec 01, 2017 at 06:04:32PM +0000, Andre Przywara wrote: > Hi, > > On 20/11/17 19:16, Christoffer Dall wrote: > > We are about to distinguish between userspace accesses and mmio traps > > for a number of the mmio handlers. When the requester vcpu is NULL, it > > mens we are handling a userspace acccess. > > > > Factor out the functionality to get the request vcpu into its own > > function, mostly so we have a common place to document the semantics of > > the return value. > > > > Also take the chance to move the functionality outside of holding a > > spinlock and instead explicitly disable and enable preemption. This > > supports PREEMPT_RT kernels as well. > > > > Acked-by: Marc Zyngier <marc.zyngier@xxxxxxx> > > Signed-off-by: Christoffer Dall <christoffer.dall@xxxxxxxxxx> > > --- > > virt/kvm/arm/vgic/vgic-mmio.c | 43 +++++++++++++++++++++++++++---------------- > > 1 file changed, 27 insertions(+), 16 deletions(-) > > > > diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c > > index deb51ee16a3d..6113cf850f47 100644 > > --- a/virt/kvm/arm/vgic/vgic-mmio.c > > +++ b/virt/kvm/arm/vgic/vgic-mmio.c > > @@ -122,6 +122,26 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu, > > return value; > > } > > > > +/* > > + * This function will return the VCPU that performed the MMIO access and > > + * trapped from twithin the VM, and will return NULL if this is a userspace > > + * access. > > + * > > + * We can disable preemption locally around accessing the per-CPU variable > > + * because even if the current thread is migrated to another CPU, reading the > > + * per-CPU value later will give us the same value as we update the per-CPU > > + * variable in the preempt notifier handlers. > > This comment left me scratching my head a bit. Maybe you could change it > to point out that ... it's safe to *enable* preemption after the call > again, because of said reasons? Because disabling preemption before > accessing a per-CPU variable is not really an issue. I'll try to clarify. > > Apart from that it's fine. > > Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx> > Thanks, -Christoffer
