Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751337AbdFBHUF (ORCPT ); Fri, 2 Jun 2017 03:20:05 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37896 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751218AbdFBHTH (ORCPT ); Fri, 2 Jun 2017 03:19:07 -0400 Subject: Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste To: Martin Schwidefsky Cc: Heiko Carstens , David Hildenbrand , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Huth References: <20170529163202.13077-1-david@redhat.com> <20170601124651.3e7969ab@mschwideX1> <20170602070210.GA4221@osiris> <20170602091638.5583cfb2@mschwideX1> From: Christian Borntraeger Date: Fri, 2 Jun 2017 09:18:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170602091638.5583cfb2@mschwideX1> Content-Type: text/plain; charset=utf-8 Content-Language: en-IE Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17060207-0024-0000-0000-0000168EC019 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007157; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000212; SDB=6.00868952; UDB=6.00431944; IPR=6.00648917; BA=6.00005393; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015675; XFM=3.00000015; UTC=2017-06-02 07:19:04 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17060207-0025-0000-0000-00004B3074F5 Message-Id: <787556bd-2c20-48e8-edd4-f4c5c5a5eaaf@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-02_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706020138 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2389 Lines: 48 On 06/02/2017 09:16 AM, Martin Schwidefsky wrote: > On Fri, 2 Jun 2017 09:13:03 +0200 > Christian Borntraeger wrote: > >> On 06/02/2017 09:02 AM, Heiko Carstens wrote: >>> On Thu, Jun 01, 2017 at 12:46:51PM +0200, Martin Schwidefsky wrote: >>>>> Unfortunately, converting all page tables to 4k pgste page tables is >>>>> not possible without provoking various race conditions. >>>> >>>> That is one approach we tried and was found to be buggy. The point is that >>>> you are not allowed to reallocate a page table while a VMA exists that is >>>> in the address range of that page table. >>>> >>>> Another approach we tried is to use an ELF flag on the qemu executable. >>>> That does not work either because fs/exec.c allocates and populates the >>>> new mm struct for the argument pages before fs/binfmt_elf.c comes into >>>> play. >>> >>> How about if you would fail the system call within arch_check_elf() if you >>> detect that the binary requires pgstes (as indicated by elf flags) and then >>> restart the system call? >>> >>> That is: arch_check_elf() e.g. would set a thread flag that future mm's >>> should be allocated with pgstes. Then do_execve() would cleanup everything >>> and return to entry.S. Upon return to userspace we detect this condition >>> and simply restart the system call, similar to signals vs -ERESTARTSYS. >>> >>> That would make do_execve() cleanup everything and upon reentering it would >>> allocate an mm with the pgste flag set. >>> >>> Maybe this is a bit over-simplified, but might work. >>> >>> At least I also don't like the next "hack", that is specifically designed >>> to only work with how QEMU is currently implemented. It might break with >>> future QEMU changes or the next user space implementation that drives the >>> kvm interface, but is doing everything differently. >>> Let's look for a "clean" solution that will always work. We had too many >>> hacks for this problem and *all* of them were broken. >> >> >> The more I think about it, dropping 2k page tables and always allocate a full >> page would simplify pgalloc. As far I can see this would also get rid of >> the &mm->context.pgtable_lock. > > And it would waste twice the amount of memory for page tables. NAK. Yes and we spend the same amount of memory TODAY, because every distro on the planet that uses KVM has sysctl.allocate_pgste set.