From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/4] kvm-s390: add capability indicating COW support Date: Tue, 15 May 2012 15:40:04 +0300 Message-ID: <4FB24EA4.2030503@redhat.com> References: <1337084128-38219-1-git-send-email-borntraeger@de.ibm.com> <1337084128-38219-2-git-send-email-borntraeger@de.ibm.com> <4FB24B11.1050607@redhat.com> <4FB24CB5.3070606@de.ibm.com> <4FB24D0D.7090707@redhat.com> <4FB24E46.1050600@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tossati , Carsten Otte , Alexander Graf , Jens Freimann , Cornelia Huck , Heiko Carstens , Martin Schwidefsky , Heinz Graalfs , KVM To: Christian Borntraeger Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27595 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932092Ab2EOMkt (ORCPT ); Tue, 15 May 2012 08:40:49 -0400 In-Reply-To: <4FB24E46.1050600@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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