Re: [RFC PATCH 0/2] Expose available KVM free memory slot count to help avoid aborts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 25, 2011 at 12:20:03PM +0200, Avi Kivity wrote:
> On 01/24/2011 11:32 AM, Marcelo Tosatti wrote:
> >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.
> >
> >Its not difficult to either increase the maximum number (defined as
> >32 now in both qemu and kernel) of static slots, or support dynamic
> >increases, if it turns out to be a performance issue.
> >
> 
> We can't make it unbounded in the kernel, since a malicious user
> could start creating an infinite amount of memory slots, pinning
> unbounded kernel memory.

How about keeping the slots in userspace memory, access them with copy
from user?

> If we make the limit much larger, we should start to think about
> efficiency.  Every mmio vmexit is currently a linear scan of the
> memory slot table, which is efficient at a small number of slots,
> but not at a large number.  We could conceivably encode the "no
> slot" information into a bit in the not-present spte.

OK, but the slots that Alex here wants to use are presumably
mostly not resulting in a pagefault at all, right?
Can we split such guys out so they don't slow mmio lookup?
Maybe keep *these* in userspace memory.

> -- 
> error compiling committee.c: too many arguments to function
--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux