* Pekka Enberg <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
