Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp408520pxb; Thu, 21 Apr 2022 02:15:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWWQnO7uke8H0e9WKowW7lCduDku82bmLsTtEwRG8V46axno6jghUBz3OPDd5Tv6ulPD/d X-Received: by 2002:a05:6402:5187:b0:423:deb7:f6cd with SMTP id q7-20020a056402518700b00423deb7f6cdmr23250764edd.177.1650532536924; Thu, 21 Apr 2022 02:15:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650532536; cv=none; d=google.com; s=arc-20160816; b=Bzfs0K84PpZ5ONWX8QxtEu9A9vN1SCzh0rsLtEogNsp4V2zvtlIaPRvn7aU5tWLNCV Im2EqC5IxSBPb87bchwLPzSLjWf1DroiPTaZUUFxzf02SFGOqdvsAmOuHGxACOT+4Myb Ij6f/guYvZHX7zoSah3FfU5rN8EOuDH390hUCXYyJ9OC29VG+UM1upIu6X/Ow/74wMEu Osb/RPs9pmW6Nn+kX2g4/l60kOBFd6OC6wrG+mdbIALr/Bems465Rkubj5q63h+MLA9H 90NWDztDukmzamKJkKbresA9tnSurBwfyvxBqaLAz/ZCczB44nKUOJjpmcmDstiQYWqt aYPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=Cl61Yr8fx8HaDn+oC//jmcXW/JcUHkhj9+RjIkf8Agc=; b=k4puwPv+SHsfuaUZO727YXJ/FdKyCk5la7/Kbh0OxtljCRE30k50AOEGZ2p52AP3qG /1Xp5k+Q3/YjbdlkL/98fSVzP/Sw91jxnsuM9XbRxGdHBRyFWsbpSJDXk3KLgEA0fAEe IrJQezVkWhkwGLZFmIPguAT6j53Oq2dkrXhEd3vU4tUrKl5GTi4xzMtrk8g2HGHF7Ag7 8pib0OQVCrx/Bc8Gqm4a/RC1ecCeBdcogQ3LkWvE+CFUTXjba7r7w4QyBf2hkRMuT/Ed g5ZfHQ+TFKmT7mQbiKXgMbUm3FjGhB2mHvdj6nvtZca0sj4X6yi+VtMNzYEbpSPlm0R7 mHIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iaOMCyRQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ay7-20020a170906d28700b006e88cd8b684si3466275ejb.727.2022.04.21.02.15.11; Thu, 21 Apr 2022 02:15:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iaOMCyRQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237958AbiDRTNp (ORCPT + 99 others); Mon, 18 Apr 2022 15:13:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231361AbiDRTNn (ORCPT ); Mon, 18 Apr 2022 15:13:43 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD77F31225 for ; Mon, 18 Apr 2022 12:11:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 92ED7B81060 for ; Mon, 18 Apr 2022 19:11:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A80A8C385A7; Mon, 18 Apr 2022 19:11:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650309061; bh=FqMrB3LTVheJzBcEVjR9TRPvl3+5WxICePYJ9H+WYRE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=iaOMCyRQAZv6m5n78HaBURxK4NMMAN9CI4xs+oSzDJbyFRw0xw+JmtcXEZiLYs6f6 sWQZINgA/mWWsVjHbXZpZgKYQBG/nbrRkzD9Ng31J6SrfwKPZnCBJ4uvKKloxPuIYU gmBsGOVzZg3RriB3VWqZ9plK2DvIAG+cH3w10+YrNfgRh2sngFmSSehrUFTciYqu7T zT5w8FDN0R3R3txesKnzG9aufRHfEwzLWhFmgeulNNrs5UcXMXLPapHGO/BNvf2NOf jC57LqnXClajT8Mqetp1AltnOuq2ME4B5BFkhuLGN6A/2//wMDcXj42G2e90kh+jIQ zqiUjbXtEVKYw== Date: Mon, 18 Apr 2022 12:11:00 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Oleksandr cc: Christoph Hellwig , Stefano Stabellini , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Oleksandr Tyshchenko , Boris Ostrovsky , Juergen Gross , Julien Grall , "Michael S. Tsirkin" Subject: Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio devices in Xen guests In-Reply-To: Message-ID: References: <1649963973-22879-1-git-send-email-olekstysh@gmail.com> <1649963973-22879-7-git-send-email-olekstysh@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Apr 2022, Oleksandr wrote: > On 16.04.22 09:07, Christoph Hellwig wrote: > > Hello Christoph > > > On Fri, Apr 15, 2022 at 03:02:45PM -0700, Stefano Stabellini wrote: > > > This makes sense overall. Considering that the swiotlb-xen case and the > > > virtio case are mutually exclusive, I would write it like this: > > Curious question: Why can't the same grant scheme also be used for > > non-virtio devices? I really hate having virtio hooks in the arch > > dma code. Why can't Xen just say in DT/ACPI that grants can be used > > for a given device? [...] > This patch series tries to make things work with "virtio" devices in Xen > system without introducing any modifications to code under drivers/virtio. Actually, I think Christoph has a point. There is nothing inherently virtio specific in this patch series or in the "xen,dev-domid" device tree binding. Assuming a given device is emulated by a Xen backend, it could be used with grants as well. For instance, we could provide an emulated e1000 NIC with a "xen,dev-domid" property in device tree. Linux could use grants with it and the backend could map the grants. It would work the same way as virtio-net/block/etc. Passthrough devices wouldn't have the "xen,dev-domid" property, so no problems. So I think we could easily generalize this work and expand it to any device. We just need to hook on the "xen,dev-domid" device tree property. I think it is just a matter of: - remove the "virtio,mmio" check from xen_is_virtio_device - rename xen_is_virtio_device to something more generic, like xen_is_grants_device - rename xen_virtio_setup_dma_ops to something more generic, like xen_grants_setup_dma_ops And that's pretty much it.