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

["Michael S. Tsirkin" <mst@redhat.com>]

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.

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