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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6729FC433F5 for ; Tue, 19 Apr 2022 13:29:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OP/aiUDLi3b3dxQzI+ByK9Aw84QBgXqInO8qptEKmXs=; b=Q1JTqQLZBiRbWPzXzyHb4Zl16v 92f94HyzXyv6J0q5j+pjEvZGWMYXiI2/HhTAZ1dxjyHtdUwKy5GBv/wvvjXm04uW5/rzE+YipZhot paxdNa1u/rHYEb/fBqIlpfDYJKT/UmsDifBKgTbNEZaq4QJYKRhw1JSxtjtTv1Ebhy2jYgLXAzUPk jpQRevxfN/Ar4AjvM9PFhR1dl5w3vP+ITWj4+ZjITHvuFZZUO6hjxc10G1cjlNAFDRTj3XL30xS/F hPArLYII0VDR+YV4LwQufPGm5pkk0IezRXvQ80ng+KQK3UDU+Qmk6To7sBRNjUS7xuWUe0yUM4zLS QmdJfSzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ngnsO-003piK-No; Tue, 19 Apr 2022 13:26:41 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ngmnS-003PeG-PU for linux-arm-kernel@lists.infradead.org; Tue, 19 Apr 2022 12:17:33 +0000 Received: by mail-lf1-x130.google.com with SMTP id d6so11350313lfv.9 for ; Tue, 19 Apr 2022 05:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=c4jLu+nEjW6ZyZXVzGI5SDD7yHtnUvhBe/fmRqUVNIQ=; b=XHTyOUDABQ14gZmVv1k6ZT33I2aAbve42wB0HyHQxv7GIG6L7ZAKcuW2rGSxXu/ygr JnWzRmFHo9x1ZE21q1MdOXNxgM0G6U0dzM3232itmYKA3MVrjrU/MLuccHMgIGDrN3hH D3+yMStuFAvLXza9j2W/bcrz9OIx2WmpcXkiVEVsqxbasDR23Ydv/wFqPV9IL4cz2XuP +09gFQTuxn7+b56CTrbPi8/Pq6zYk0zHk6sQvCLKjT9J2p/G9SV4KjVtjs3cOMisAS2O mivwFNQc84cRhVQafMN71BdlBSk1jKUOclNnS4aoAd2n+l9UOg0Iyj5GA7Yfjtxo1el9 KIRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=c4jLu+nEjW6ZyZXVzGI5SDD7yHtnUvhBe/fmRqUVNIQ=; b=ww4GTBqs8HX4U7o4MoH6ijPZ1Ob7CC1T2nP6jpD4oLHD7E29d5nOh3OKP0Fa24VLwD Heb4URQTvtwcvkn8fbZiDtobMHqOfbRXwrpLCT5jCRzS5dTQ/gPikYy5hOs8pdggmpaB ccyOSWfs8bKCKTt5Q4hGPoiVi4avF81/UjAb8CIpFBbIOQR5ISp6TUNjDAz7oBLaAneD M7/FazK5p3V4fQMN7Faai8wBXlvC/JyesEP785vFLsXySqCatPhiFIJaXNk7Euno9vts Yg2qli/VtOSyQuXYQBlEjP6JDYyDpK4ArgO8KQkEuzxa0GSbkp3aLMceQXziXgOY8NlM 5cyA== X-Gm-Message-State: AOAM531Cd68ZJyRisaMp/2OZwLfWGTbnXaRVrLJ4V9AHuWXjxQLG4+5o LpHxy2yW28c8O+lnOLu3Y2bZBeyhy0c= X-Google-Smtp-Source: ABdhPJwkKAkPv72l8VLD2wXgvdqXMSxh5RJKyI64dvC+KXpqtAP43wJmw6LIPT1nv21iuUsXGSy77w== X-Received: by 2002:a05:6512:c28:b0:471:9a7d:de9e with SMTP id z40-20020a0565120c2800b004719a7dde9emr5320943lfu.440.1650370646660; Tue, 19 Apr 2022 05:17:26 -0700 (PDT) Received: from [192.168.1.7] ([212.22.223.21]) by smtp.gmail.com with ESMTPSA id e15-20020a19500f000000b0046bb76678bcsm1497380lfb.131.2022.04.19.05.17.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Apr 2022 05:17:26 -0700 (PDT) Subject: Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio devices in Xen guests To: Stefano Stabellini , Juergen Gross Cc: Christoph Hellwig , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Oleksandr Tyshchenko , Boris Ostrovsky , Julien Grall , "Michael S. Tsirkin" References: <1649963973-22879-1-git-send-email-olekstysh@gmail.com> <1649963973-22879-7-git-send-email-olekstysh@gmail.com> From: Oleksandr Message-ID: <6a04cc34-fbb3-44d8-c1a4-03bda5b3deb1@gmail.com> Date: Tue, 19 Apr 2022 15:17:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220419_051730_939555_B0E47D42 X-CRM114-Status: GOOD ( 31.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Stefano, Juergen On 18.04.22 22:11, Stefano Stabellini wrote: > 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. Although the main intention of this series was to enable using virtio devices in Xen guests, I agree that nothing in new DMA ops layer (xen-virtio.c) is virtio specific (at least at the moment). Regarding the whole patch series I am not quite sure, as it uses arch_has_restricted_virtio_memory_access(). > 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. + likely renaming everything in that patch series not to mention virtio (mostly related to xen-virtio.c internals). Stefano, thank you for clarifying Christoph's point. Well, I am not against going this direction. Could we please make a decision on this? @Juergen, what is your opinion? -- Regards, Oleksandr Tyshchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel