public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC 0/9] Memory registration rework
@ 2008-08-13  0:48 Glauber Costa
  2008-08-13  0:48 ` [PATCH 1/9] add debuging facilities to memory registration at libkvm Glauber Costa
  2008-08-13 11:43 ` [RFC 0/9] Memory registration rework Avi Kivity
  0 siblings, 2 replies; 16+ messages in thread
From: Glauber Costa @ 2008-08-13  0:48 UTC (permalink / raw)
  To: kvm; +Cc: avi, aliguori


Hi folks,

The following series contain a proposal for our memory registration
framework. This is by no means complete, and rather, a first step only.

This first step, btw, has the goal of taking the kvm-specific memory registration
functions from all over the code, so we can make the merging with qemu easier.

Note that I'm putting kvm_cpu_register_phys_memory() _inside_ cpu_register_phys_memory().
To do that, we need to be resilient against the same region being registered multiple times,
and should be able to interpret the flags embedded in phys_offset in a meaninful way.
Although arguably with some bugs yet unknown, this series does exactly that.

For that to work, we have to be sure that we'll never reach a situation in which we
register a piece of memory, and later on, register another region that contains it. Current
code does that, so we're fine. The oposite situation, namely, registering a large piece of memory
and then re-registering pieces of it, is perfectly valid.

In the to-be-merged version, if it ever exists, I intend to comment all those issues very well,
to get an as predictable interface as possible.

There's another option of doing this, as anthony pointed out in earlier private comments to me,
which is scanning the already registered regions right before starting execution, and building our
maps. While this is valid, we can't run away from doing what I'm doing, because some areas are
manipulated _after_ the machine has started. For example, the pci region, for the hotplug case.

Note that this is not tested in anything but x86. 

Comments welcome.



^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2008-08-13 14:33 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-13  0:48 [RFC 0/9] Memory registration rework Glauber Costa
2008-08-13  0:48 ` [PATCH 1/9] add debuging facilities to memory registration at libkvm Glauber Costa
2008-08-13  0:48   ` [PATCH 2/9] experimental change to avoid doing the same thing twice Glauber Costa
2008-08-13  0:48     ` [PATCH 3/9] do not use mem_hole anymore Glauber Costa
2008-08-13  0:48       ` [PATCH 4/9] allow intersecting region to be on the boundary Glauber Costa
2008-08-13  0:48         ` [PATCH 5/9] substitute is_allocated_mem with more general is_containing_region Glauber Costa
2008-08-13  0:48           ` [PATCH 6/9] move kvm_cpu_register_memory_area into qemu's Glauber Costa
2008-08-13  0:48             ` [PATCH 7/9] cleanup kvm memory registration Glauber Costa
2008-08-13  0:48               ` [PATCH 8/9] coalesce mmio regions without an explicit call Glauber Costa
2008-08-13  0:48                 ` [PATCH 9/9] remove explicit calls to kvm_qemu_register_coalesced_mmio Glauber Costa
2008-08-13 14:11             ` [PATCH 6/9] move kvm_cpu_register_memory_area into qemu's Anthony Liguori
2008-08-13 14:33               ` Glauber Costa
2008-08-13 11:41           ` [PATCH 5/9] substitute is_allocated_mem with more general is_containing_region Avi Kivity
2008-08-13 13:02             ` Glauber Costa
2008-08-13 11:43 ` [RFC 0/9] Memory registration rework Avi Kivity
2008-08-13 14:13   ` Anthony Liguori

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox