Re: [RFC 0/7] Introduce swiotlb throttling

2024-08-28 Thread Petr Tesařík
On Wed, 28 Aug 2024 16:30:04 + Michael Kelley wrote: > From: Petr Tesařík Sent: Wednesday, August 28, 2024 6:04 AM > > > > On Wed, 28 Aug 2024 13:02:31 +0100 > > Robin Murphy wrote: > > > > > On 2024-08-22 7:37 pm, mhkelle...@gmail.com w

Re: [RFC 0/7] Introduce swiotlb throttling

2024-08-28 Thread Petr Tesařík
On Wed, 28 Aug 2024 13:02:31 +0100 Robin Murphy wrote: > On 2024-08-22 7:37 pm, mhkelle...@gmail.com wrote: > > From: Michael Kelley > > > > Background > > == > > Linux device drivers may make DMA map/unmap calls in contexts that > > cannot block, such as in an interrupt handler. Conseq

Re: [RFC 1/7] swiotlb: Introduce swiotlb throttling

2024-08-27 Thread Petr Tesařík
On Tue, 27 Aug 2024 17:30:59 + Michael Kelley wrote: > From: Petr Tesařík Sent: Tuesday, August 27, 2024 8:56 AM > > > > On Fri, 23 Aug 2024 20:41:15 + > > Michael Kelley wrote: > > > > > From: Petr Tesařík Sent: Friday, August 23, 2024 12:41 &

Re: [RFC 1/7] swiotlb: Introduce swiotlb throttling

2024-08-27 Thread Petr Tesařík
On Fri, 23 Aug 2024 20:41:15 + Michael Kelley wrote: > From: Petr Tesařík Sent: Friday, August 23, 2024 12:41 AM > > > > On Thu, 22 Aug 2024 11:37:12 -0700 > > mhkelle...@gmail.com wrote: >[...] > > > @@ -71,12 +72,15 @@ > > > *

Re: [RFC 0/7] Introduce swiotlb throttling

2024-08-27 Thread Petr Tesařík
On Tue, 27 Aug 2024 00:26:36 + Michael Kelley wrote: > From: Petr Tesařík Sent: Monday, August 26, 2024 12:28 PM > > > > On Mon, 26 Aug 2024 16:24:53 + > > Michael Kelley wrote: > > > > > From: Petr Tesařík Sent: Saturday, August 24, 2024 &g

Re: [RFC 0/7] Introduce swiotlb throttling

2024-08-26 Thread Petr Tesařík
On Mon, 26 Aug 2024 16:24:53 + Michael Kelley wrote: > From: Petr Tesařík Sent: Saturday, August 24, 2024 1:06 PM > > > > On Fri, 23 Aug 2024 20:40:16 + > > Michael Kelley wrote: > > > > > From: Petr Tesařík Sent: Thurs

Re: [RFC 0/7] Introduce swiotlb throttling

2024-08-24 Thread Petr Tesařík
On Fri, 23 Aug 2024 20:40:16 + Michael Kelley wrote: > From: Petr Tesařík Sent: Thursday, August 22, 2024 11:45 PM >[...] > > > Discussion > > > == > > > * Since swiotlb isn't visible to device drivers, I've specifically > >

Re: [RFC 2/7] dma: Handle swiotlb throttling for SGLs

2024-08-24 Thread Petr Tesařík
On Fri, 23 Aug 2024 20:42:08 + Michael Kelley wrote: > From: Petr Tesařík Sent: Friday, August 23, 2024 1:03 AM > > > > On Thu, 22 Aug 2024 11:37:13 -0700 > > mhkelle...@gmail.com wrote: > > > > > From: Michael Kelley > > > > > &g

Re: [RFC 7/7] nvme: Enable swiotlb throttling for NVMe PCI devices

2024-08-23 Thread Petr Tesařík
On Thu, 22 Aug 2024 11:37:18 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > In a CoCo VM, all DMA-based I/O must use swiotlb bounce buffers > because DMA cannot be done to private (encrypted) portions of VM > memory. The bounce buffer memory is marked shared (decrypted) at > boot t

Re: [RFC 6/7] nvme: Move BLK_MQ_F_BLOCKING indicator to struct nvme_ctrl

2024-08-23 Thread Petr Tesařík
On Thu, 22 Aug 2024 11:37:17 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > The NVMe setting that controls the BLK_MQ_F_BLOCKING flag on the > request queue is currently a flag in struct nvme_ctrl_ops, where > it is not writable. A new use case needs this flag to be writable > base

Re: [RFC 5/7] scsi: storvsc: Enable swiotlb throttling

2024-08-23 Thread Petr Tesařík
On Thu, 22 Aug 2024 11:37:16 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > In a CoCo VM, all DMA-based I/O must use swiotlb bounce buffers > because DMA cannot be done to private (encrypted) portions of VM > memory. The bounce buffer memory is marked shared (decrypted) at > boot t

Re: [RFC 4/7] scsi_lib_dma: Add _attrs variant of scsi_dma_map()

2024-08-23 Thread Petr Tesařík
On Thu, 22 Aug 2024 11:37:15 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > Extend the SCSI DMA mapping interfaces by adding the "_attrs" variant > of scsi_dma_map(). This variant allows passing DMA_ATTR_* values, such > as is needed to support swiotlb throttling. The existing scsi

Re: [RFC 3/7] dma: Add function for drivers to know if allowing blocking is useful

2024-08-23 Thread Petr Tesařík
On Thu, 22 Aug 2024 11:37:14 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > With the addition of swiotlb throttling functionality, storage > device drivers may want to know whether using the DMA_ATTR_MAY_BLOCK > attribute is useful. In a CoCo VM or environment where swiotlb=force >

Re: [RFC 2/7] dma: Handle swiotlb throttling for SGLs

2024-08-23 Thread Petr Tesařík
On Thu, 22 Aug 2024 11:37:13 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > When a DMA map request is for a SGL, each SGL entry results in an > independent mapping operation. If the mapping requires a bounce buffer > due to running in a CoCo VM or due to swiotlb=force on the boot l

Re: [RFC 1/7] swiotlb: Introduce swiotlb throttling

2024-08-23 Thread Petr Tesařík
On Thu, 22 Aug 2024 11:37:12 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > Implement throttling of swiotlb map requests. Because throttling requires > temporarily pending some requests, throttling can only be used by map > requests made in contexts that can block. Detecting such c

Re: [RFC 0/7] Introduce swiotlb throttling

2024-08-22 Thread Petr Tesařík
Hi all, upfront, I've had more time to consider this idea, because Michael kindly shared it with me back in February. On Thu, 22 Aug 2024 11:37:11 -0700 mhkelle...@gmail.com wrote: > From: Michael Kelley > > Background > == > Linux device drivers may make DMA map/unmap calls in context

Re: [RFC 0/7] Introduce swiotlb throttling

2024-08-22 Thread Petr Tesařík
On Fri, 23 Aug 2024 02:20:41 + Michael Kelley wrote: > From: Bart Van Assche Sent: Thursday, August 22, 2024 > 12:29 PM > > > > On 8/22/24 11:37 AM, mhkelle...@gmail.com wrote: > > > Linux device drivers may make DMA map/unmap calls in contexts that > > > cannot block, such as in an inte