linux-kernel - [KVM PATCH] xinterface

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: <20090716150323.29318.17714.stgit@dev.haskins.net>
Date:	Thu, 16 Jul 2009 11:19:40 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	kvm@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, avi@...hat.com, glommer@...hat.com,
	aliguori@...ibm.com
Subject: [KVM PATCH] xinterface

(Applies to kvm.git/master:84a3c081)

For details, please read the patch header.

Background: The original vbus code was tightly integrated with kvm.ko.  Avi
suggested that we abstract the interfaces such that it could live outside
of kvm.  Part of that discussion turned into what is now irqfd/ioeventfd
checked into kvm.git.  The other part of the discussion (pointer-translation)
was suggested to be addressed by having the memory-slot info replicated
across interested modules.

I was looking into what is required for essentially hooking the
SET_MEMORY_REGION operations in QEMU yesterday by talking to Anthony and
Glauber on IRC.  We came to the conclusion that we could possibly
do a minor cleanup on the various callsites of SET_MEMORY_REGION so that
a wrapper function was used.  I could then add a hook at this wrapper
to essentially get notification events whenever memory-slots change, and
could forward this info to my module appropriate.

Anthony made the observation that replicating the slots info is
not the cleanest design, and I tend to agree with him.  Its replicating
data and is going to be prone to synchronization problems, etc.  He
also mentioned that other modules like virtio-net would want access
to this same information at some point, so perhaps a general solution was in
order. 

Therefore, I stepped back from that initial approach of replicating slots
and instead provided a abstract mechanism to utilize the original structures.

This code has been tested with a prototype of the vbus-v4 code and appears
to function properly.

Comments/suggestions?

Regards,
-Greg

---

Gregory Haskins (1):
      KVM: introduce "xinterface" API for external interaction with guests

 arch/x86/Kbuild                |    4 +
 arch/x86/kvm/Makefile          |    4 +
 arch/x86/kvm/x86.c             |    1 
 include/linux/kvm.h            |    2 +
 include/linux/kvm_host.h       |    6 ++
 include/linux/kvm_xinterface.h |   58 ++++++++++++++++
 virt/kvm/kvm_main.c            |   72 ++++++++++++++++++++
 virt/kvm/xinterface.c          |  147 ++++++++++++++++++++++++++++++++++++++++
 8 files changed, 293 insertions(+), 1 deletions(-)
 create mode 100644 include/linux/kvm_xinterface.h
 create mode 100644 virt/kvm/xinterface.c

-- 
Signature
--
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/