linux-kernel - [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-next>] [day] [month] [year] [list]

Message-ID: <20120720161841.15119.29653.stgit@bling.home>
Date:	Fri, 20 Jul 2012 10:33:34 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	avi@...hat.com, mst@...hat.com
Cc:	gleb@...hat.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	jan.kiszka@...mens.com
Subject: [PATCH v6 0/2] kvm: level irqfd and new eoifd

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,

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/