* Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote: > On 5/11/11 9:21 AM, Sasha Levin wrote: > >If you feel the 512MB vs guest_flat_to_host() trade-off is worth it, > >I'll change it to work that way. > > Why would it not be? This is 64-bit only, right? There's plenty of virtual > address space and mprotect() should make sure we never allocate physical > pages for it. Sure, there's some in-kernel overhead involved as well, but > that's extremely small. > > I'm not worried about performance in guest_flat_to_host() but I think the > current implementation is not very clean. If you want to mmap() two separate > regions, we should have our own internal "memory map" that's used for this > (and for populating KVM end E820 maps). > > So I think mmap'ing the gap is the cleanest solution for now. We can revisit > the decision if we need even more regions in the future. Agreed. There's also admittedly somewhat of a conceptual beauty in having a linearly addressable chunk of *all* guest physical RAM on the hypervisor side. Virtualization involves so many indirections to begin with that keeping the mental picture simpler is helpful IMHO ... Thanks, Ingo -- 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
