Re: RFC/patch portability: split kvm_vm_ioctl v2

Izik Eidus
2007-10-25T16:42:01Z

On Thu, 2007-10-25 at 11:22 -0500, Hollis Blanchard wrote:
> On Thu, 2007-10-25 at 17:48 +0200, Izik Eidus wrote:
> > On Thu, 2007-10-25 at 17:48 +0200, Carsten Otte wrote:
> > > This patch splits kvm_vm_ioctl into archtecture independent parts, and
> > > x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
> > >
> > > Common ioctls for all architectures are:
> > > KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION
> > >
> > > KVM_SET_USER_MEMORY_REGION is actually implemented in x86.c now, because
> > > the code behind looks arch specific to me.
>
> Reviewed-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> > i think it is much better just to split the parts that allocate the
> > rmap, and the part that set the number of shadow pages mmu,
> > beside this parts it seems to me that it isnt arch specific.
>
> Carsten omitted the explanation about memslots he had in his original
> patch. To quote that here:
> > We've got a total different
> > address layout on s390: we cannot support multiple slots, and a user
> > memory range always equals the guest physical memory [guest_phys + vm
> > specific offset = host user address]. We don't have nor need dedicated
> > vmas for the guest memory, we just use what the memory managment has
> > in stock. This is true, because we reuse the page table for user and
> > guest mode.
>
> Given that explanation, and that kvm_vm_ioctl_set_memory_region() is
> entirely about memslots, I'm inclined to agree with this code movement.
>
after reading this, i agree.
sorry.