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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 37F20C433ED for ; Fri, 14 May 2021 10:08:23 +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 E6E0E61454 for ; Fri, 14 May 2021 10:08:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6E0E61454 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=freebsd.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.127322.239271 (Exim 4.92) (envelope-from ) id 1lhUjl-00067P-Pu; Fri, 14 May 2021 10:08:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 127322.239271; Fri, 14 May 2021 10:08:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lhUjl-00067I-Mt; Fri, 14 May 2021 10:08:05 +0000 Received: by outflank-mailman (input) for mailman id 127322; Fri, 14 May 2021 10:08:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lhUjk-00067A-Ld for xen-devel@lists.xenproject.org; Fri, 14 May 2021 10:08:04 +0000 Received: from mx2.freebsd.org (unknown [2610:1c1:1:606c::19:2]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d55b3dde-8f08-4378-9e93-fa6d2c2f3489; Fri, 14 May 2021 10:08:03 +0000 (UTC) Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 076D78682A; Fri, 14 May 2021 10:08:03 +0000 (UTC) (envelope-from royger@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FhPNf6XZDz3FKW; Fri, 14 May 2021 10:08:02 +0000 (UTC) (envelope-from royger@freebsd.org) Received: from localhost (unknown [93.176.185.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: royger) by smtp.freebsd.org (Postfix) with ESMTPSA id 6FCB7236D9; Fri, 14 May 2021 10:08:02 +0000 (UTC) (envelope-from royger@freebsd.org) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d55b3dde-8f08-4378-9e93-fa6d2c2f3489 Date: Fri, 14 May 2021 12:07:53 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julien Grall Cc: Elliott Mitchell , xen-devel@lists.xenproject.org, Mitchell Horne Subject: Re: Uses of /hypervisor memory range (was: FreeBSD/Xen/ARM issues) Message-ID: References: <54427968-9b13-36e6-0001-27fb49f85635@xen.org> <93936406-574f-7fd0-53bf-3bafaa4b1947@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <93936406-574f-7fd0-53bf-3bafaa4b1947@xen.org> On Fri, May 14, 2021 at 09:32:10AM +0100, Julien Grall wrote: > Hi Elliott, > > On 14/05/2021 03:42, Elliott Mitchell wrote: > > Was it intended for the /hypervisor range to dynamically scale with the > > size of the domain? > As per above, this doesn't depend on the size of the domain. Instead, this > depends on what sort of the backend will be present in the domain. It should instead scale based on the total memory on the system, ie: if your hardware has 4GB of RAM the unpopulated range should at least be: 4GB - memory of the current domain, so that it could map any possible page assigned to a different domain (and even then I'm not sure we shouldn't account for duplicated mappings). > > Might it be better to deprecate the /hypervisor range and have domains > > allocate any available address space for foreign mappings? > > It may be easy for FreeBSD to find available address space but so far this > has not been the case in Linux (I haven't checked the latest version > though). > > To be clear, an OS is free to not use the range provided in /hypervisor > (maybe this is not clear enough in the spec?). This was mostly introduced to > overcome some issues we saw in Linux when Xen on Arm was introduced. > > > > > Should the FreeBSD implementation be treating grant tables as distinct > > from other foreign mappings? > > Both require unallocated addres space to work. IIRC FreeBSD is able to find > unallocated space easily, so I would recommend to use it. I agree. I think the main issue here is that there seems to be some bug (or behavior not understood properly) with the resource manager on Arm that returns an error when requesting a region anywhere in the memory address space, ie: [0, ~0]. > > (is treating them the same likely to > > induce buggy behavior on x86?) > > I will leave this answer to Roger. x86 is already treating them the same by using xenmem_alloc to request memory to map the grant table or foreign mappings, so there's no change on x86 in that regard. Maybe I'm not getting that last question right. Roger.