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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
