search for: dma_addr_is_phys_addr

From: Thiago Jung Bauermann <bauerman at linux.ibm.com> In order to safely use the DMA API, virtio needs to know whether DMA addresses are in fact physical addresses and for that purpose, dma_addr_is_phys_addr() is introduced. cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> cc: David Gibson <david at gibson.dropbear.id.au> cc: Michael Ellerman <mpe at ellerman.id.au> cc: Paul Mackerras <paulus at ozlabs.org> cc: Michael Roth <mdroth at linux.vnet.ibm.com> cc: Alexe...

...gt; On Fri, Oct 11, 2019 at 06:25:18PM -0700, Ram Pai wrote: >> From: Thiago Jung Bauermann <bauerman at linux.ibm.com> >> >> In order to safely use the DMA API, virtio needs to know whether DMA >> addresses are in fact physical addresses and for that purpose, >> dma_addr_is_phys_addr() is introduced. >> >> cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> >> cc: David Gibson <david at gibson.dropbear.id.au> >> cc: Michael Ellerman <mpe at ellerman.id.au> >> cc: Paul Mackerras <paulus at ozlabs.org> >> cc: Michae...

On Fri, Oct 11, 2019 at 06:25:18PM -0700, Ram Pai wrote: > From: Thiago Jung Bauermann <bauerman at linux.ibm.com> > > In order to safely use the DMA API, virtio needs to know whether DMA > addresses are in fact physical addresses and for that purpose, > dma_addr_is_phys_addr() is introduced. > > cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> > cc: David Gibson <david at gibson.dropbear.id.au> > cc: Michael Ellerman <mpe at ellerman.id.au> > cc: Paul Mackerras <paulus at ozlabs.org> > cc: Michael Roth <mdroth at li...

On Fri, Oct 11, 2019 at 06:25:18PM -0700, Ram Pai wrote: > From: Thiago Jung Bauermann <bauerman at linux.ibm.com> > > In order to safely use the DMA API, virtio needs to know whether DMA > addresses are in fact physical addresses and for that purpose, > dma_addr_is_phys_addr() is introduced. > > cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> > cc: David Gibson <david at gibson.dropbear.id.au> > cc: Michael Ellerman <mpe at ellerman.id.au> > cc: Paul Mackerras <paulus at ozlabs.org> > cc: Michael Roth <mdroth at li...

...required: hypervisor would be happy to get access to all of guest memory. That's why it does not set VIRTIO_F_ACCESS_PLATFORM. However, guest decides that it does not trust the hypervisor and wants to force a bounce buffer for its own reasons. Thiago Jung Bauermann (2): dma-mapping: Add dma_addr_is_phys_addr() virtio_ring: Use DMA API if memory is encrypted arch/powerpc/include/asm/dma-mapping.h | 21 +++++++++++++++++++++ arch/powerpc/platforms/pseries/Kconfig | 1 + drivers/virtio/virtio.c | 18 ++++++++++++++++++ drivers/virtio/virtio_ring.c | 8 ++++++++ include/linux...

...mply can't use DMA API with a legacy device. Otherwise, on a SEV system with an IOMMU which isn't 1:1 and with a virtio device without ACCESS_PLATFORM, we are trying to pass a virtual address, and devices without ACCESS_PLATFORM can only access CPU physical addresses. So something like: dma_addr_is_phys_addr? -- MST

...mply can't use DMA API with a legacy device. Otherwise, on a SEV system with an IOMMU which isn't 1:1 and with a virtio device without ACCESS_PLATFORM, we are trying to pass a virtual address, and devices without ACCESS_PLATFORM can only access CPU physical addresses. So something like: dma_addr_is_phys_addr? -- MST

...gt; > > Otherwise, on a SEV system with an IOMMU which isn't 1:1 > and with a virtio device without ACCESS_PLATFORM, we are trying > to pass a virtual address, and devices without ACCESS_PLATFORM > can only access CPU physical addresses. > > So something like: > > dma_addr_is_phys_addr? On our Secure pseries platform, dma address is physical address and this proposal will help us, use DMA API. On our normal pseries platform, dma address is physical address too. But we do not necessarily need to use the DMA API. We can use the DMA API, but our handlers will do the same thing...

sev_active() is gone now in linux-next, at least as a global API. And once again this is entirely going in the wrong direction. The only way using the DMA API is going to work at all is if the device is ready for it. So we need a flag on the virtio device, exposed by the hypervisor (or hardware for hw virtio devices) that says: hey, I'm real, don't take a shortcut. And that means on

sev_active() is gone now in linux-next, at least as a global API. And once again this is entirely going in the wrong direction. The only way using the DMA API is going to work at all is if the device is ready for it. So we need a flag on the virtio device, exposed by the hypervisor (or hardware for hw virtio devices) that says: hey, I'm real, don't take a shortcut. And that means on

...+ * + * The DMA API can be used either when the device doesn't have the IOMMU quirk, + * or when the DMA API is guaranteed to always return physical addresses. + */ +static inline bool virtio_can_use_dma_api(const struct virtio_device *vdev) +{ + return !virtio_has_iommu_quirk(vdev) || + dma_addr_is_phys_addr(vdev->dev.parent); +} + static inline struct virtqueue *virtio_find_single_vq(struct virtio_device *vdev, vq_callback_t *c, const char *n) -- 1.8.3.1

...+ * + * The DMA API can be used either when the device doesn't have the IOMMU quirk, + * or when the DMA API is guaranteed to always return physical addresses. + */ +static inline bool virtio_can_use_dma_api(const struct virtio_device *vdev) +{ + return !virtio_has_iommu_quirk(vdev) || + dma_addr_is_phys_addr(vdev->dev.parent); +} + static inline struct virtqueue *virtio_find_single_vq(struct virtio_device *vdev, vq_callback_t *c, const char *n) -- 1.8.3.1