linux-kernel - Re: [PATCH v6 0/2] kvm: level irqfd and new eoifd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1343083857.2229.323.camel@bling.home>
Date:	Mon, 23 Jul 2012 16:50:57 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	avi@...hat.com
Cc:	mst@...hat.com, gleb@...hat.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, jan.kiszka@...mens.com
Subject: Re: [PATCH v6 0/2] kvm: level irqfd and new eoifd

On Fri, 2012-07-20 at 10:33 -0600, Alex Williamson wrote:
> v6:
> 
> So we're back to just the first two patches, unfortunately the
> diffstat got bigger though.  The reason for that is that I discovered
> we don't do anything on release of an eoifd.  We cleanup if the kvm
> vm is released, but we're dealing with a constrained resource of irq
> source IDs, so I think it's best that we cleanup to make sure those
> are returned.  To do that we need nearly the same infrastructure as
> irqfd, we just only watch for POLLHUP.  So while there's more code
> here, the structure and function names line up identically to irqfd.
> 
> The other big change here is that KVM_IRQFD returns a token when
> setting up a level irqfd.  We use this token to associate the eoifd
> with the right source.  This means we have to put the struct
> _source_ids on a list so we can find them.  This removes the weird
> interaction we were headed to where the eoifd is associated with
> the eventfd of the irqfd.  There's potentially more flexibility for
> the future here too as we might come up with other interfaces that
> can return a source ID "key".  Perhaps some future KVM_IRQFD will
> allow specifying a key for re-attaching.  Anyway, the sequence
> Michael pointed out where an irqfd is de-assigned then re-assigned
> now results in a new key instead of leaving the user wondering if
> it re-associates back to the eoifd.
> 
> Also added workqueue flushes on assign since releasing either
> object now results in a lazy release via workqueue.  This ensures
> we re-claim any source IDs we can.  Thanks,

FYI, I seem to have found a new locking issue in this version.  I'll
send an update when I find it.  Thanks,

Alex

> ---
> 
> Alex Williamson (2):
>       kvm: KVM_EOIFD, an eventfd for EOIs
>       kvm: Extend irqfd to support level interrupts
> 
> 
>  Documentation/virtual/kvm/api.txt |   32 ++-
>  arch/x86/kvm/x86.c                |    3 
>  include/linux/kvm.h               |   18 +
>  include/linux/kvm_host.h          |   17 +
>  virt/kvm/eventfd.c                |  463 ++++++++++++++++++++++++++++++++++++-
>  virt/kvm/kvm_main.c               |   11 +
>  6 files changed, 536 insertions(+), 8 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/