From: Alex Williamson <alex.williamson@redhat.com>
To: qemu-devel@nongnu.org, anthony@codemonkey.ws, blauwirbel@gmail.com
Cc: alex.williamson@redhat.com, kvm@vger.kernel.org
Subject: [Qemu-devel] [PATCH v4 0/2] Minimal RAM API support
Date: Mon, 13 Dec 2010 14:24:23 -0700 [thread overview]
Message-ID: <20101213212059.2472.17879.stgit@s20.home> (raw)
Update per comments, Thanks,
Alex
v4:
- ram_slot -> RamSlot (per CODING_STYLE)
- drop qemu_ prefix from functions (per CODING_STYLE)
- mallocz -> malloc
- drop extraneous return from void function
v3:
- Address review comments
- pc registers all memory below 4G in one chunk
Let me know if there are any further issues.
v2:
- Move to Makefile.objs
- Move structures to memory.c and create a callback function
- Fix memory leak
I haven't moved to the state parameter because there should only
be a single instance of this per VM. The state parameter seems
like it would add complications in setup and function calling, but
maybe point me to an example if I'm off base.
v1:
For VFIO based device assignment, we need to know what guest memory
areas are actual RAM. RAMBlocks have long since become a grab bag
of misc allocations, so aren't effective for this. Anthony has had
a RAM API in mind for a while now that addresses this problem. This
implements just enough of it so that we have an interface to get
actual guest memory physical addresses to setup the host IOMMU. We
can continue building a full RAM API on top of this stub.
Anthony, feel free to add copyright to memory.c as it's based on
your initial implementation. I had to add something since the file
in your branch just copies a header with Frabrice's copywrite.
---
Alex Williamson (2):
RAM API: Make use of it for x86 PC
Minimal RAM API support
Makefile.objs | 1 +
cpu-common.h | 2 +
hw/pc.c | 9 ++---
memory.c | 94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
memory.h | 44 +++++++++++++++++++++++++++
5 files changed, 144 insertions(+), 6 deletions(-)
create mode 100644 memory.c
create mode 100644 memory.h
next reply other threads:[~2010-12-13 21:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-13 21:24 Alex Williamson [this message]
2010-12-13 21:24 ` [Qemu-devel] [PATCH v4 1/2] Minimal RAM API support Alex Williamson
2010-12-15 17:23 ` Paul Brook
2010-12-15 19:11 ` Alex Williamson
2010-12-15 19:34 ` Anthony Liguori
2010-12-13 21:24 ` [Qemu-devel] [PATCH v4 2/2] RAM API: Make use of it for x86 PC Alex Williamson
2010-12-14 9:18 ` [Qemu-devel] " Avi Kivity
2010-12-14 15:16 ` Alex Williamson
2010-12-14 15:18 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101213212059.2472.17879.stgit@s20.home \
--to=alex.williamson@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=blauwirbel@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).