From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29296C433DF for ; Sun, 17 May 2020 09:31:49 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B96DB206D5 for ; Sun, 17 May 2020 09:31:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B96DB206D5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=antioche.eu.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jaFdU-0002PU-PD; Sun, 17 May 2020 09:31:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jaFdT-0002PP-En for xen-devel@lists.xenproject.org; Sun, 17 May 2020 09:31:07 +0000 X-Inumbo-ID: 21754fe2-9821-11ea-b9cf-bc764e2007e4 Received: from chassiron.antioche.eu.org (unknown [2001:41d0:fe9d:1101::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 21754fe2-9821-11ea-b9cf-bc764e2007e4; Sun, 17 May 2020 09:31:05 +0000 (UTC) Received: from rochebonne.antioche.eu.org (rochebonne [10.0.0.1]) by chassiron.antioche.eu.org (8.15.2/8.15.2) with ESMTP id 04H9UxNV023817; Sun, 17 May 2020 11:30:59 +0200 (MEST) Received: by rochebonne.antioche.eu.org (Postfix, from userid 1210) id 28AED2810; Sun, 17 May 2020 11:30:59 +0200 (CEST) Date: Sun, 17 May 2020 11:30:59 +0200 From: Manuel Bouyer To: Andrew Cooper Subject: Re: IOCTL_PRIVCMD_MMAPBATCH on Xen 4.13.0 Message-ID: <20200517093059.GD1820@antioche.eu.org> References: <20200515202912.GA11714@antioche.eu.org> <20200515210629.GA10976@antioche.eu.org> <20200515215335.GA9991@antioche.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (chassiron.antioche.eu.org [151.127.5.145]); Sun, 17 May 2020 11:30:59 +0200 (MEST) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sat, May 16, 2020 at 05:18:45PM +0100, Andrew Cooper wrote: > On 15/05/2020 22:53, Manuel Bouyer wrote: > > On Fri, May 15, 2020 at 10:38:13PM +0100, Andrew Cooper wrote: > >>> [...] > >>> Does it help ? > >> Yes and no.  This is collateral damage of earlier bug. > >> > >> What failed was xen_init_fv()'s > >> > >>     shared_page = xc_map_foreign_range(xc_handle, domid, XC_PAGE_SIZE, > >>                                        PROT_READ|PROT_WRITE, ioreq_pfn); > >>     if (shared_page == NULL) { > >>         fprintf(logfile, "map shared IO page returned error %d\n", errno); > >>         exit(-1); > >>     } > >> > >> because we've ended up with a non-NULL pointer with no mapping behind > >> it, hence the SIGSEGV for the first time we try to use the pointer. > >> > >> Whatever logic is behind xc_map_foreign_range() should have returned > >> NULL or a real mapping. > > What's strange is that the mapping is validated, by mapping it in > > the dom0 kernel space. But when we try to remap in in the process's > > space, it fails. > > Hmm - this sounds like a kernel bug I'm afraid. no I don't think it is. It works with Xen 4.11, and it works with 4.13 for PV/PVH domUs. Maybe there's a missing flag in the PTE of some sort that is mandatory for 4.13 but not 4.11 for userland PTE but it doens't look obvious. The difference could be that the kernel page tables are active when mapping the foreing page in the dom0's kernel space, but the user process page table it not (obviously, as we're in the kernel when doing the mapping). -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --