Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751164AbdFBKsM (ORCPT ); Fri, 2 Jun 2017 06:48:12 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:49903 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751125AbdFBKsK (ORCPT ); Fri, 2 Jun 2017 06:48:10 -0400 Date: Fri, 2 Jun 2017 12:48:02 +0200 From: Martin Schwidefsky To: Heiko Carstens Cc: David Hildenbrand , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Huth , Christian Borntraeger Subject: Re: [PATCH RFC 0/2] KVM: s390: avoid having to enable vm.alloc_pgste In-Reply-To: <20170602102848.GC4221@osiris> References: <20170529163202.13077-1-david@redhat.com> <20170601124651.3e7969ab@mschwideX1> <20170602070210.GA4221@osiris> <20170602114647.35e6d30f@mschwideX1> <20170602102848.GC4221@osiris> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17060210-0012-0000-0000-00000543361E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17060210-0013-0000-0000-000018AFD488 Message-Id: <20170602124802.2df9cec5@mschwideX1> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-02_05:,, 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-1706020199 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1525 Lines: 44 On Fri, 2 Jun 2017 12:28:48 +0200 Heiko Carstens wrote: > On Fri, Jun 02, 2017 at 11:46:47AM +0200, Martin Schwidefsky wrote: > > On Fri, 2 Jun 2017 09:02:10 +0200 > > Heiko Carstens wrote: > > > Maybe this is a bit over-simplified, but might work. > > This is not over-simplified at all, that does work: > > Good! > > > +struct arch_elf_state { > > +}; > > + > > +#define INIT_ARCH_ELF_STATE { } > > + > > +#define arch_elf_pt_proc(ehdr, phdr, elf, interp, state) (0) > > +#define arch_check_elf(ehdr, interp, interp_ehdr, state) \ > > +({ \ > > + struct elf64_hdr *hdr = (void*) ehdr; \ > > + int _rc = 0; \ > > + if (hdr->e_ident[EI_CLASS] == ELFCLASS64 && \ > > + (hdr->e_flags & 0x00000002) && \ > > + !page_table_allocate_pgste && \ > > + !current->mm->context.alloc_pgste) { \ > > + current->mm->context.alloc_pgste = 1; \ > > However, I think this is over-simplified, unless I'm mistaken. > > If you set current->mm->context.alloc_pgste here, then that means that 4k > page tables will be freed when the original mm will be released, instead of > the correct 2k ones. > > I think you need an additional intermediate context flag here. Something > like current->mm->context.request_pgste or whatever, no? Yes, the flags for the current mm and the next mm have to be different. request_pgste is a nice name for the new flag, I'll use it. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.