Re: [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

Avi Kivity
2007-10-26T10:36:32Z

Carsten Otte wrote:
> Avi Kivity wrote:
>> I don't really see a big difference between what we have now (sparse
>> userspace, sparse guest) and Izik's idea (contiguous userspace,
>> sparse guest). In both cases you need something like memory slots to
>> describe the different sections.
> We don't on s390: we receive a page fault by the guest once it
> accesses a sparse hole in its address space. We check the user space's
> VMA and either page it in or submit an addressing exception to the guest.

I was talking about x86.

On x86, you need contiguous userspace, contiguous guest, but again,
what's the problem with one memory slot?

>
>> Moreover, on x86 you may want different properties for different
>> sections (4K pages for the framebuffer, large pages for main memory),
>> so you can't allocate memory in one big chunk.
> That's right. On s390, we can live with whatever properties a section
> has with regard to page size, backing device and such. So memory may
> well come to live by different alloations, and different allocation
> methods. All we need is a permanent contiguous mapping of the guest
> physical addresses to host user addresses. So Izik's idea would work
> for us even if we have different sections.

So would the current memory slot thing, no?

--
error compiling committee.c: too many arguments to function