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

[Avi Kivity <avi@redhat.com>]

On 01/25/2011 05:23 PM, Michael S. Tsirkin wrote:
> On Tue, Jan 25, 2011 at 04:58:41PM +0200, Avi Kivity wrote:
> >  On 01/25/2011 04:55 PM, Michael S. Tsirkin wrote:
> >  >>
> >  >>   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?
> >
> >  Some of the data is validated by the kernel, so it needs a kernel
> >  copy.  Other fields are completely internal to the kernel.
> >
> >  >>   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.
> >
> >  The algorithm is:
> >
> >    page fault:
> >      for each slot:
> >         if addr in slot:
> >            populate spte
> >            return
> >      # no slot matches
> >      mmio
> >
> >  so we have to try out all slots before we find out none of them are needed.
>
> I see now. Yes, a flag in spte would help.  changes in slots would then
> have to update all these flags.

That's easy, we drop all sptes.

-- 
error compiling committee.c: too many arguments to function