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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F923C433F5 for ; Wed, 13 Oct 2021 11:53:16 +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 E384461040 for ; Wed, 13 Oct 2021 11:53:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E384461040 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=xenproject.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.208277.364338 (Exim 4.92) (envelope-from ) id 1macoY-0007Bf-HN; Wed, 13 Oct 2021 11:52:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 208277.364338; Wed, 13 Oct 2021 11:52:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1macoY-0007BY-EH; Wed, 13 Oct 2021 11:52:54 +0000 Received: by outflank-mailman (input) for mailman id 208277; Wed, 13 Oct 2021 11:52:53 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1macoX-0007BS-Lk for xen-devel@lists.xenproject.org; Wed, 13 Oct 2021 11:52:53 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1macoX-0003lF-Fp for xen-devel@lists.xenproject.org; Wed, 13 Oct 2021 11:52:53 +0000 Received: from iwj (helo=mariner.uk.xensource.com) by xenbits.xenproject.org with local-bsmtp (Exim 4.92) (envelope-from ) id 1macoX-0000tV-Er for xen-devel@lists.xenproject.org; Wed, 13 Oct 2021 11:52:53 +0000 Received: from iwj by mariner.uk.xensource.com with local (Exim 4.89) (envelope-from ) id 1macoK-0007S5-Mc; Wed, 13 Oct 2021 12:52:40 +0100 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=References:In-Reply-To:Subject:Cc:To:Date :Message-ID:Content-Transfer-Encoding:Content-Type:MIME-Version:From; bh=2WT0kmTFC401nOY6M3W3ge4h8W9JrHrW5ZPpi0UGoSk=; b=sP5GiQbNM2L8mqQTBYSkou6WQC drzvEmYIy+NCdOHZcp6IrweYv5EWDMF4WSee/+1u0KdiPRVJbvrxI4oNR27nnHntXywX+M+cUvXpU DPme82L4ftb1mWRCCPrZ8b3FYRNeg14k0Mlz7+89K4Jn/VGTH1Vsaj/T7Ar65wW3e+Z4=; From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <24934.51335.791795.638185@mariner.uk.xensource.com> Date: Wed, 13 Oct 2021 12:52:39 +0100 To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: Stefano Stabellini , Bertrand Marquis , Jan Beulich , Oleksandr Andrushchenko , Rahul Singh , "xen-devel\@lists.xenproject.org" , Andre Przywara , Wei Liu , Juergen Gross Subject: Re: [PATCH v5 01/11] xen/arm: xc_domain_ioport_permission(..) not supported on ARM. In-Reply-To: References: <0744b957-1832-dff2-9ae2-b8e8534f501b@suse.com> <09656882-b297-7144-c291-1ee997edb119@suse.com> <69A83587-B7E0-4653-AF8C-AEE802922CE5@arm.com> <24933.41349.893363.203683@mariner.uk.xensource.com> <24933.47094.43672.782143@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) Roger Pau Monné writes ("Re: [PATCH v5 01/11] xen/arm: xc_domain_ioport_permission(..) not supported on ARM."): > On Tue, Oct 12, 2021 at 01:42:22PM -0700, Stefano Stabellini wrote: > > I don't think it is about performance. From a performance point of view, > > we could make as many (unneeded) hypercalls as required. It is mostly > > about minimizing unwanted changes to common libxl code. Let me explain. Thanks. This summary is helpful And, pleasingly, it matches what I had thought I had gleaned from the thread. > > All options above achieve the goal of a successful domain creation with > > PCI device assigned on ARM. You might be able to think of other options > > as well. I think noone here is really set on using one option over the > > other -- as long as xc_domain_ioport_permission failures don't turn into > > domain creation failures on ARM we are good. > > I think having a libxl_arch_io_ports_supported helper could be the > cleaner way to do this. For x86 it will unconditionally return true, > while for Arm you could consider poking at > XEN_DOMCTL_ioport_permission and see if it returns ENOSYS or > otherwise. > I guess it's possible that in the future we allow IO ports access on > Arm guests using some kind of emulated mechanism if the need arises, > at which point the hypercall will be implemented. I agree with Roger. So I think I would like to see a version of this patch which * Introduces libxl_arch_io_ports_supported. (I am fine with it just returning false, unconditionally on Arm, ie in libxl_arm.c.) * Has a commit message explaining what is actually going on. Cutting and pasting liberally from your email seems like it would be a very good starting point. Even discussion of rejected alternatives is fine, if it seems like it fits. I'm quite unlikely to object to a commit message on grounds that it's too long. Thanks, Ian.