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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
