Re: [PATCH v4 2/3] kvm: KVM_EOIFD, an eventfd for EOIs

[Alex Williamson <alex.williamson@redhat.com>]

On Sun, 2012-07-15 at 19:32 +0300, Michael S. Tsirkin wrote:
> On Fri, Jul 13, 2012 at 01:41:05PM -0600, Alex Williamson wrote:
> > +static int kvm_assign_eoifd(struct kvm *kvm, struct kvm_eoifd *args)
> > +{
> > +	struct eventfd_ctx *level_irqfd = NULL, *eventfd = NULL;
> > +	struct _eoifd *eoifd = NULL;
> > +	struct _irq_source *source = NULL;
> > +	unsigned gsi;
> > +	int ret;
> > +
> > +	eventfd = eventfd_ctx_fdget(args->fd);
> > +	if (IS_ERR(eventfd)) {
> > +		ret = PTR_ERR(eventfd);
> > +		goto fail;
> > +	}
> > +
> > +	eoifd = kzalloc(sizeof(*eoifd), GFP_KERNEL);
> > +	if (!eoifd) {
> > +		ret = -ENOMEM;
> > +		goto fail;
> > +	}
> > +
> > +	if (args->flags & KVM_EOIFD_FLAG_LEVEL_IRQFD) {
> > +		struct _irqfd *irqfd = _irqfd_fdget_lock(kvm, args->irqfd);
> > +		if (IS_ERR(irqfd)) {
> > +			ret = PTR_ERR(irqfd);
> > +			goto fail;
> > +		}
> > +
> > +		gsi = irqfd->gsi;
> > +		level_irqfd = eventfd_ctx_get(irqfd->eventfd);
> > +		source = _irq_source_get(irqfd->source);
> > +		_irqfd_put_unlock(irqfd);
> > +		if (!source) {
> > +			ret = -EINVAL;
> > +			goto fail;
> > +		}
> > +	} else {
> > +		ret = -EINVAL;
> > +		goto fail;
> > +	}
> > +
> > +	INIT_LIST_HEAD(&eoifd->list);
> > +	eoifd->kvm = kvm;
> > +	eoifd->eventfd = eventfd;
> > +	eoifd->source = source;
> > +	eoifd->level_irqfd = level_irqfd;
> > +	eoifd->notifier.gsi = gsi;
> > +	eoifd->notifier.irq_acked = eoifd_event;
> > +
> > +	mutex_lock(&kvm->eoifds.lock);
> > +
> > +	list_add_tail(&eoifd->list, &kvm->eoifds.items);
> 
> Do we want to disallow multiple eventfds mapping the same irqfd?
> No strong opinions but preventing this might make it possible to cache
> the callback in the irqfd in the future.
> 
> This will also help limit the number of eoifd-s to 1024 GSIs * 32 source ids.
> As it is userspace can apparently consume unlimited kernel memory.

So your concern is that if you have a single irqfd and a single eventfd,
KVM_EOIFD could be called in a loop and each time time through we'd
allocate a struct _eoifd until the kernel falls over?  Sounds like a
problem.  You've already pushed for allowing the eventfd to be
multiplexed, so seems like our only choice is to test for irqfd re-use.
So each irqfd can only be tied to a single eoifd, but multiple irqfds
may be tied to the same eoifd.  Seems like a fairly easy change.
Thanks,

Alex