On 05/15/2012 03:38 PM, Christian Borntraeger wrote: > On 15/05/12 14:33, Avi Kivity wrote: > > On 05/15/2012 03:31 PM, Christian Borntraeger wrote: > >> On 15/05/12 14:24, Avi Kivity wrote: > >>>> Newer systems allow to write-protect the guest backing memory > >>>> and let the fault be delivered to the host, thus allowing COW. > >>>> > >>>> Use a capability bit to tell qemu if that is possible. > >>>> > >>> > >>> Asking out of ignorance: who is doing the write protection here? The > >>> guest? If so, why is qemu involved? > >> > >> It is about the host doing write protection of guest/user memory (e.g. for > >> dirty pages tracking or KSM) > > > > Ok, so why does qemu^Wuserspace need to know about it? > > By default qemu will use MAP_PRIVATE for guest pages. This will write > protect pages and thus break on s390 systems that dont support this feature. > Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED > has other problems (no dirty pages tracking, a lot more swap overhead etc.) > With this feature qemu can use the standard qemu alloc if available, otherwise > it will use the old s390 hack. I will put you on cc for the qemu patch :-) Yeah, I even have vague memories of the hack. Thanks for the clarifications. -- 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
