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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 9A986C12002 for ; Fri, 16 Jul 2021 18:29:18 +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 BD5B9613F8 for ; Fri, 16 Jul 2021 18:29:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD5B9613F8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=cs.pub.ro 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.157681.290396 (Exim 4.92) (envelope-from ) id 1m4SZz-0002tj-LU; Fri, 16 Jul 2021 18:28:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 157681.290396; Fri, 16 Jul 2021 18:28:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1m4SZz-0002tc-He; Fri, 16 Jul 2021 18:28:55 +0000 Received: by outflank-mailman (input) for mailman id 157681; Fri, 16 Jul 2021 18:28:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1m4SZy-0002tW-Ea for xen-devel@lists.xenproject.org; Fri, 16 Jul 2021 18:28:54 +0000 Received: from mx.upb.ro (unknown [141.85.13.221]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d17edcb9-a963-436a-a980-07be32fe60ec; Fri, 16 Jul 2021 18:28:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx.upb.ro (Postfix) with ESMTP id BC65BB5600A4; Fri, 16 Jul 2021 21:28:50 +0300 (EEST) Received: from mx.upb.ro ([127.0.0.1]) by localhost (mx.upb.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2VKC7S7Qb5Ep; Fri, 16 Jul 2021 21:28:48 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by mx.upb.ro (Postfix) with ESMTP id 71FBFB5600B2; Fri, 16 Jul 2021 21:28:48 +0300 (EEST) Received: from mx.upb.ro ([127.0.0.1]) by localhost (mx.upb.ro [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BSx4MdhDdz8l; Fri, 16 Jul 2021 21:28:48 +0300 (EEST) Received: from [192.168.1.35] (unknown [82.78.48.31]) by mx.upb.ro (Postfix) with ESMTPSA id 8F5C6B5600A4; Fri, 16 Jul 2021 21:28:47 +0300 (EEST) 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: d17edcb9-a963-436a-a980-07be32fe60ec X-Virus-Scanned: amavisd-new at upb.ro Subject: Re: [PATCH] stubdom: foreignmemory: Fix build after 0dbb4be739c5 To: Juergen Gross , Julien Grall , Jan Beulich Cc: Julien Grall , Ian Jackson , Wei Liu , xen-devel@lists.xenproject.org, Andrew Cooper References: <20210713092019.7379-1-julien@xen.org> <0698e4b1-8fb9-919e-e9a2-1b135a808e3e@suse.com> <756ba923-17a6-0889-cc7e-bcd43a5eb258@citrix.com> <3505f2da-4c41-f5ca-d775-814d038d5bad@xen.org> <3c819563-b354-5527-050d-f698324d6021@xen.org> <65d35862-304c-7fe3-82de-3ff62f06529a@suse.com> <40c00267-60d2-c0fc-cde4-8ac4ce936f87@suse.com> <69c62b4c-b46f-9eab-8dfd-742c07423424@suse.com> <7fab704a-6b59-1e9b-663e-a3afdfcc319f@suse.com> From: Costin Lupu Message-ID: <3a6f1fc6-a9b3-78bc-1b73-b7ad10d20405@cs.pub.ro> Date: Fri, 16 Jul 2021 21:28:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <7fab704a-6b59-1e9b-663e-a3afdfcc319f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/13/21 6:20 PM, Juergen Gross wrote: > On 13.07.21 17:15, Julien Grall wrote: >> Hi Juergen, >> >> On 13/07/2021 16:09, Juergen Gross wrote: >>> On 13.07.21 16:38, Julien Grall wrote: >>>> Hi Juergen, >>>> >>>> On 13/07/2021 15:23, Juergen Gross wrote: >>>>> On 13.07.21 16:19, Julien Grall wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On 13/07/2021 15:14, Jan Beulich wrote: >>>>>>>> And I don't think it should be named XC_PAGE_*, but rather >>>>>>>> XEN_PAGE_*. >>>>>>> >>>>>>> Even that doesn't seem right to me, at least in principle. There >>>>>>> shouldn't >>>>>>> be a build time setting when it may vary at runtime. IOW on Arm I >>>>>>> think a >>>>>>> runtime query to the hypervisor would be needed instead. >>>>>> >>>>>> Yes, we want to be able to use the same userspace/OS without >>>>>> rebuilding to a specific hypervisor page size. >>>>> >>>>> This define is used for accessing data of other domains. See the >>>>> define >>>>> for XEN_PAGE_SIZE in xen/include/public/io/ring.h >>>>> >>>>> So it should be a constant (minimal) page size for all hypervisors = and >>>>> guests of an architecture. >>>> >>>> Do you mean the maximum rather than minimal? If you use the minimal >>>> (4KB), then you would not be able to map the page in the stage-2 if >>>> the hypervisor is using 64KB. >>> >>> But this would mean that the current solution to use XC_PAGE_SIZE is >>> wrong, as this is 4k. >> >> The existing ABI is implicitely based on using the hypervisor page >> granularity (currently 4KB). >> >> There is really no way we can support existing guest on 64KB >> hypervisor. But if we were going to break them, then we should >> consider to do one of the following option: >> =C2=A0=C2=A0=C2=A0 1) use 64KB page granularity for ABI >> =C2=A0=C2=A0=C2=A0 2) query the hypervisor page granularity at runtime >> >> The ideal is 2) because it is more scalable for the future. We also >> need to consider to extend the PV protocol so the backend and frontend >> can agree on the page size. >=20 > I absolutely agree, but my suggestion was to help finding a proper way > to cleanup the current interface mess. And this should be done the way > I suggested IMO. >=20 > A later interface extension for future guests can still be done on top > of that. Alright, let's have a little recap to see if I got it right and to agree on the next steps. There are 2 proposed solutions, let's say a static one and a dynamic one. 1) Static solution (proposed by Juergen) - We define XEN_PAGE_* values in a xen/include/public/arch-*/*.h header. - Q: Should we define a new header for that? page.h or page_size.h are ok as new filenames? Pros: - We fix the interfaces mess and we can get rid of xenctrl lib dependency for some of the libs that need only the XEN_PAGE_* definitions= . - It's faster to implement, with fewer changes. Cons: - Well, it's static, it doesn't allow the hypervisor to provide different values for different guests. 2) Dynamic solution (proposed by Jan and Julien) We get the value(s) by calling a hypcall, probably as a query related to some guest domain. Pros: - It's dynamic and scalable. We would support different values for different guests. Cons: - More difficult to implement. It changes the paradigm in the toolstack libs, every occurrence of XC_PAGE_* would have to be amended. Moreover, we might want to make the hypcall once and save the value for later (probably several toolstack structures should be extended for that) I searched for the occurrences of XC_PAGE_* in the toolstack libs and it's a *lot* of them. IMHO I think we should pick the static solution for now, considering that it would be faster to implement. Please let me know if this is OK or not. Any comments are appreciated. Cheers, Costin