On Fri, Jan 21, 2011 at 04:48:02PM -0700, Alex Williamson wrote: > When doing device assignment, we use cpu_register_physical_memory() to > directly map the qemu mmap of the device resource into the address > space of the guest. The unadvertised feature of the register physical > memory code path on kvm, at least for this type of mapping, is that it > needs to allocate an index from a small, fixed array of memory slots. > Even better, if it can't get an index, the code aborts deep in the > kvm specific bits, preventing the caller from having a chance to > recover. > > It's really easy to hit this by hot adding too many assigned devices > to a guest (pretty easy to hit with too many devices at instantiation > time too, but the abort is slightly more bearable there). > > I'm assuming it's pretty difficult to make the memory slot array > dynamically sized. If that's not the case, please let me know as > that would be a much better solution. > > I'm not terribly happy with the solution in this series, it doesn't > provide any guarantees whether a cpu_register_physical_memory() will > succeed, only slightly better educated guesses. > > Are there better ideas how we could solve this? Thanks, > > Alex Put the table in qemu memory, make kvm access it with copy from/to user? It can then be any size ... > --- > > Alex Williamson (2): > device-assignment: Count required kvm memory slots > kvm: Allow querying free slots > > > hw/device-assignment.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++- > hw/device-assignment.h | 3 ++ > kvm-all.c | 16 +++++++++++++ > kvm.h | 2 ++ > 4 files changed, 79 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
