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.2 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 C7AF6C433E0 for ; Fri, 29 May 2020 07:35:56 +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 9E5852074D for ; Fri, 29 May 2020 07:35:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E5852074D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com 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 1jeZY7-0006WW-E7; Fri, 29 May 2020 07:35:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jeZY6-0006WR-4Y for xen-devel@lists.xenproject.org; Fri, 29 May 2020 07:35:26 +0000 X-Inumbo-ID: f52bc116-a17e-11ea-8993-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f52bc116-a17e-11ea-8993-bc764e2007e4; Fri, 29 May 2020 07:35:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A12EEB032; Fri, 29 May 2020 07:35:22 +0000 (UTC) Subject: Re: [RFC PATCH 1/1] xen: Use a global mapping for runstate To: Julien Grall References: <03e7cd740922bfbaa479f22d81d9de06f718a305.1590675919.git.bertrand.marquis@arm.com> From: Jan Beulich Message-ID: Date: Fri, 29 May 2020 09:35:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Stefano Stabellini , Wei Liu , "paul@xen.org" , Andrew Cooper , "Xia, Hongyan" , Ian Jackson , George Dunlap , Bertrand Marquis , xen-devel@lists.xenproject.org, nd@arm.com, Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 28.05.2020 20:54, Julien Grall wrote: > On 28/05/2020 16:25, Bertrand Marquis wrote: >> At the moment on Arm, a Linux guest running with KTPI enabled will >> cause the following error when a context switch happens in user mode: >> (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xffffff837ebe0cd0 >> >> This patch is modifying runstate handling to map the area given by the >> guest inside Xen during the hypercall. >> This is removing the guest virtual to physical conversion during context >> switches which removes the bug > > It would be good to spell out that a virtual address is not stable. So > relying on it is wrong. Guests at present are permitted to change the mapping underneath the virtual address provided (this may not be the best idea, but the interface is like it is). Therefore I don't think the present interface can be changed like this. Instead a new interface will need adding which takes a guest physical address instead. (Which, in the end, will merely be one tiny step towards making the hypercall interfaces use guest physical addresses. And it would be nice if an overall concept was hashed out first how that conversion should occur, such that the change here could at least be made fit that planned model. For example, an option might be to retain all present hypercall numbering and simply dedicate a bit in the top level hypercall numbers indicating whether _all_ involved addresses for that operation are physical vs virtual ones.) Jan