linux-kernel - Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio devices in Xen guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 18 Apr 2022 00:05:08 +0300
From:   Oleksandr <olekstysh@...il.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Stefano Stabellini <sstabellini@...nel.org>,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>, Julien Grall <julien@....org>,
        "Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio
 devices in Xen guests


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?


In Xen system:
- the grants are not used for "non-virtualized" devices at all (platform 
devices for the passthrough).
- the grants are widely used for "virtualized, but non-virtio" devices 
(traditional Xen PV devices), but grants for these Xen PV devices
are used in a different way and *not* at the DMA ops level like in 
current approach

Or I misunderstood your question?

This patch series tries to make things work with "virtio" devices in Xen 
system without introducing any modifications to code under drivers/virtio.
We could avoid having virtio hooks in the arch DMA code, but we need to 
trigger setting xen-virtio DMA ops for the virtio device from some other 
place.
For example, the following code would also work, but requires altering 
virtio_mmio_probe():

diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 56128b9..8f48491 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -615,6 +615,9 @@ static int virtio_mmio_probe(struct platform_device 
*pdev)
                                               DMA_BIT_MASK(32 + 
PAGE_SHIFT));
         } else {
                 rc = dma_set_mask_and_coherent(&pdev->dev, 
DMA_BIT_MASK(64));
+
+               if (arch_has_restricted_virtio_memory_access())
+ xen_virtio_setup_dma_ops(&pdev->dev);
         }
         if (rc)
                 rc = dma_set_mask_and_coherent(&pdev->dev, 
DMA_BIT_MASK(32));


Another possible option could be to introduce local init function in 
drivers/xen/xen-virtio.c to scan the device tree and set xen-virtio DMA 
ops for all devices with the
"xen,dev-domid" property.


What do you think?

-- 
Regards,

Oleksandr Tyshchenko