search for: bus_dma_mask

...ea32c78 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -689,8 +689,8 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask) */ static inline bool dma_addressing_limited(struct device *dev) { - return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < - dma_get_required_mask(dev); + return min_not_zero(dma_get_mask(dev), dev->bus_dma_mask) < + dma_get_required_mask(dev); } #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS -- 2.20.1

...ea32c78 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -689,8 +689,8 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask) */ static inline bool dma_addressing_limited(struct device *dev) { - return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < - dma_get_required_mask(dev); + return min_not_zero(dma_get_mask(dev), dev->bus_dma_mask) < + dma_get_required_mask(dev); } #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS -- 2.20.1

...ere that is really what's the VM is doing to itself, which > > is to stash its memory away in an inaccessible place. > > > > Cheers, > > Ben. > > I think Christoph merely objects to the specific implementation. If > instead you do something like tweak dev->bus_dma_mask for the virtio > device I think he won't object. Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ? So, something like that would be a possibility, but the problem is that the current virtio (guest side) implementation doesn't honor this when not using dma op...

...ere that is really what's the VM is doing to itself, which > > is to stash its memory away in an inaccessible place. > > > > Cheers, > > Ben. > > I think Christoph merely objects to the specific implementation. If > instead you do something like tweak dev->bus_dma_mask for the virtio > device I think he won't object. Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ? So, something like that would be a possibility, but the problem is that the current virtio (guest side) implementation doesn't honor this when not using dma op...

...t; > > is to stash its memory away in an inaccessible place. > > > > > > > > Cheers, > > > > Ben. > > > > > > I think Christoph merely objects to the specific implementation. If > > > instead you do something like tweak dev->bus_dma_mask for the virtio > > > device I think he won't object. > > > > Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ? > > > > So, something like that would be a possibility, but the problem is that > > the current virtio (guest side)...

...t; > > is to stash its memory away in an inaccessible place. > > > > > > > > Cheers, > > > > Ben. > > > > > > I think Christoph merely objects to the specific implementation. If > > > instead you do something like tweak dev->bus_dma_mask for the virtio > > > device I think he won't object. > > > > Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ? > > > > So, something like that would be a possibility, but the problem is that > > the current virtio (guest side)...

> static inline bool dma_addressing_limited(struct device *dev) > { > - return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < > - dma_get_required_mask(dev); > + return WARN_ON_ONCE(!dev->dma_mask) ? false : > + min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < > + dma_get_required_mask(dev); This should really use a separate if statement, but I can fix that up when applying it.

When running a guest featuring a virtio-blk-pci protected with a virtual IOMMU we hit a NULL pointer dereference. This series removes the dma_max_mapping_size() call in virtio_max_dma_size when the device does not have any dma_mask set. A check is also added to early return in dma_addressing_limited() if the dma_mask is NULL. Eric Auger (2): dma-mapping: Protect dma_addressing_limited against

...emory away in an inaccessible place. > > > > > > > > > > Cheers, > > > > > Ben. > > > > > > > > I think Christoph merely objects to the specific implementation. If > > > > instead you do something like tweak dev->bus_dma_mask for the virtio > > > > device I think he won't object. > > > > > > Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ? > > > > > > So, something like that would be a possibility, but the problem is that > > > t...

On Mon, 2018-08-06 at 16:46 +0300, Michael S. Tsirkin wrote: > > > Right, we'll need some quirk to disable balloons in the guest I > > suppose. > > > > Passing something from libvirt is cumbersome because the end user may > > not even need to know about secure VMs. There are use cases where the > > security is a contract down to some special

On Mon, 2018-08-06 at 16:46 +0300, Michael S. Tsirkin wrote: > > > Right, we'll need some quirk to disable balloons in the guest I > > suppose. > > > > Passing something from libvirt is cumbersome because the end user may > > not even need to know about secure VMs. There are use cases where the > > security is a contract down to some special

...9537abc 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -689,8 +689,9 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask) */ static inline bool dma_addressing_limited(struct device *dev) { - return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < - dma_get_required_mask(dev); + return WARN_ON_ONCE(!dev->dma_mask) ? false : + min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < + dma_get_required_mask(dev); } #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS -- 2.20.1

...inux/dma-mapping.h > +++ b/include/linux/dma-mapping.h > @@ -689,8 +689,8 @@ static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask) > */ > static inline bool dma_addressing_limited(struct device *dev) > { > - return min_not_zero(*dev->dma_mask, dev->bus_dma_mask) < > - dma_get_required_mask(dev); > + return min_not_zero(dma_get_mask(dev), dev->bus_dma_mask) < > + dma_get_required_mask(dev); > } > > #ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS >

...g wrote: > On Fri, Aug 03, 2018 at 10:17:32PM +0300, Michael S. Tsirkin wrote: > > It seems reasonable to teach a platform to override dma-range > > for a specific device e.g. in case it knows about bugs in ACPI. > > A platform will be able override dma-range using the dev->bus_dma_mask > field starting in 4.19. But we'll still need a way how to > > a) document in the virtio spec that all bus dma quirks are to be > applied I agree it's a good idea. In particular I suspect that PLATFORM_IOMMU should be extended to cover that. But see below. > b)...

...M is doing to itself, which > > > is to stash its memory away in an inaccessible place. > > > > > > Cheers, > > > Ben. > > > > I think Christoph merely objects to the specific implementation. If > > instead you do something like tweak dev->bus_dma_mask for the virtio > > device I think he won't object. > > Well, we don't have "bus_dma_mask" yet ..or you mean dma_mask ? > > So, something like that would be a possibility, but the problem is that > the current virtio (guest side) implementation doesn't ho...

On Fri, Aug 03, 2018 at 12:05:07AM -0700, Christoph Hellwig wrote: > On Thu, Aug 02, 2018 at 04:13:09PM -0500, Benjamin Herrenschmidt wrote: > > So let's differenciate the two problems of having an IOMMU (real or > > emulated) which indeeds adds overhead etc... and using the DMA API. > > > > At the moment, virtio does this all over the place: > > > >

On Fri, Aug 03, 2018 at 12:05:07AM -0700, Christoph Hellwig wrote: > On Thu, Aug 02, 2018 at 04:13:09PM -0500, Benjamin Herrenschmidt wrote: > > So let's differenciate the two problems of having an IOMMU (real or > > emulated) which indeeds adds overhead etc... and using the DMA API. > > > > At the moment, virtio does this all over the place: > > > >

On Fri, Aug 03, 2018 at 10:17:32PM +0300, Michael S. Tsirkin wrote: > It seems reasonable to teach a platform to override dma-range > for a specific device e.g. in case it knows about bugs in ACPI. A platform will be able override dma-range using the dev->bus_dma_mask field starting in 4.19. But we'll still need a way how to a) document in the virtio spec that all bus dma quirks are to be applied b) a way to document in a virtio-related spec how the bus handles dma for Ben's totally fucked up hypervisor. Without that there is not wa...

On Tue, Aug 07, 2018 at 08:13:56AM +1000, Benjamin Herrenschmidt wrote: > It would be indeed ideal if all we had to do was setup some kind of > bus_dma_mask on all PCI devices and have virtio automagically insert > swiotlb when necessary. For 4.20 I plan to remove the swiotlb ops and instead do the bounce buffering in the common code, including a direct call to the direct ops to avoid retpoline overhead. For that you still need a flag in virtio th...

...into the interface > something here that is really what's the VM is doing to itself, which > is to stash its memory away in an inaccessible place. > > Cheers, > Ben. I think Christoph merely objects to the specific implementation. If instead you do something like tweak dev->bus_dma_mask for the virtio device I think he won't object. -- MST