On Tue, Jan 25, 2011 at 07:34:18PM +0200, Avi Kivity wrote: > 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. Ah, right. Hmm cpu has no flag to distinguish mmio sptes somehow already? > -- > 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
