Displaying 20 results from an estimated 10000 matches similar to: "[PATCH 1/1] virtio_ring: fix return code on DMA mapping fails"
2019 May 08
2
[PATCH 04/10] s390/mm: force swiotlb for protected virtualization
On Fri, 26 Apr 2019 20:32:39 +0200
Halil Pasic <pasic at linux.ibm.com> wrote:
> On s390, protected virtualization guests have to use bounced I/O
> buffers. That requires some plumbing.
>
> Let us make sure, any device that uses DMA API with direct ops
> correctly is spared from the problems, that a hypervisor attempting
> I/O to a non-shared page would bring.
>
>
2019 May 08
2
[PATCH 04/10] s390/mm: force swiotlb for protected virtualization
On Fri, 26 Apr 2019 20:32:39 +0200
Halil Pasic <pasic at linux.ibm.com> wrote:
> On s390, protected virtualization guests have to use bounced I/O
> buffers. That requires some plumbing.
>
> Let us make sure, any device that uses DMA API with direct ops
> correctly is spared from the problems, that a hypervisor attempting
> I/O to a non-shared page would bring.
>
>
2019 Nov 26
1
[PATCH 1/1] virtio_ring: fix return code on DMA mapping fails
On Sat, Nov 23, 2019 at 09:39:08AM -0600, Tom Lendacky wrote:
> Ideally, having a pool of shared pages for DMA, outside of standard
> SWIOTLB, might be a good thing. On x86, SWIOTLB really seems geared
> towards devices that don't support 64-bit DMA. If a device supports 64-bit
> DMA then it can use shared pages that reside anywhere to perform the DMA
> and bounce buffering. I
2019 Nov 23
0
[PATCH 1/1] virtio_ring: fix return code on DMA mapping fails
On 11/22/19 7:08 AM, Halil Pasic wrote:
> Thanks Michael!
>
> Actually I also hoped to start a discussion on virtio with encrypted
> memory.
>
> I assume the AMD folks have the most experience with this, and I very
> much like to understand how do they master the challenges we are all
> facing.
>
> My understanding of IO in the context of AMD SEV is that the user
2020 Feb 14
1
[PATCH 1/2] virtio-blk: fix hw_queue stopped on arbitrary error
Hi Halil,
When swiotlb full is hit for virtio_blk, there is below warning for once (the
warning is not by this patch set). Is this expected or just false positive?
[ 54.767257] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 16 bytes),
total 32768 (slots), used 258 (slots)
[ 54.767260] virtio-pci 0000:00:04.0: overflow 0x0000000075770110+16 of DMA
mask ffffffffffffffff bus limit 0
[
2020 Feb 13
7
[PATCH 0/2] virtio-blk: improve handling of DMA mapping failures
Two patches are handling new edge cases introduced by doing DMA mappings
(which can fail) in virtio core.
I stumbled upon this while stress testing I/O for Protected Virtual
Machines. I deliberately chose a tiny swiotlb size and have generated
load with fio. With more than one virtio-blk disk in use I experienced
hangs.
The goal of this series is to fix those hangs.
Halil Pasic (2):
2020 Feb 13
7
[PATCH 0/2] virtio-blk: improve handling of DMA mapping failures
Two patches are handling new edge cases introduced by doing DMA mappings
(which can fail) in virtio core.
I stumbled upon this while stress testing I/O for Protected Virtual
Machines. I deliberately chose a tiny swiotlb size and have generated
load with fio. With more than one virtio-blk disk in use I experienced
hangs.
The goal of this series is to fix those hangs.
Halil Pasic (2):
2020 Feb 18
2
[PATCH 1/2] virtio-blk: fix hw_queue stopped on arbitrary error
On Thu, Feb 13, 2020 at 8:38 PM Halil Pasic <pasic at linux.ibm.com> wrote:
>
> Since nobody else is going to restart our hw_queue for us, the
> blk_mq_start_stopped_hw_queues() is in virtblk_done() is not sufficient
> necessarily sufficient to ensure that the queue will get started again.
> In case of global resource outage (-ENOMEM because mapping failure,
> because of
2020 Feb 18
2
[PATCH 1/2] virtio-blk: fix hw_queue stopped on arbitrary error
On Thu, Feb 13, 2020 at 8:38 PM Halil Pasic <pasic at linux.ibm.com> wrote:
>
> Since nobody else is going to restart our hw_queue for us, the
> blk_mq_start_stopped_hw_queues() is in virtblk_done() is not sufficient
> necessarily sufficient to ensure that the queue will get started again.
> In case of global resource outage (-ENOMEM because mapping failure,
> because of
2020 Feb 19
1
[PATCH 1/2] virtio-blk: fix hw_queue stopped on arbitrary error
On Tue, Feb 18, 2020 at 8:35 PM Halil Pasic <pasic at linux.ibm.com> wrote:
>
> On Tue, 18 Feb 2020 10:21:18 +0800
> Ming Lei <tom.leiming at gmail.com> wrote:
>
> > On Thu, Feb 13, 2020 at 8:38 PM Halil Pasic <pasic at linux.ibm.com> wrote:
> > >
> > > Since nobody else is going to restart our hw_queue for us, the
> > >
2019 May 27
2
[PATCH v2 3/8] s390/cio: add basic protected virtualization support
On Mon, 27 May 2019 14:30:14 +0200
Halil Pasic <pasic at linux.ibm.com> wrote:
> On Mon, 27 May 2019 12:38:02 +0200
> Cornelia Huck <cohuck at redhat.com> wrote:
>
> > On Thu, 23 May 2019 18:22:04 +0200
> > Michael Mueller <mimu at linux.ibm.com> wrote:
> >
> > > From: Halil Pasic <pasic at linux.ibm.com>
> > >
> >
2019 May 27
2
[PATCH v2 3/8] s390/cio: add basic protected virtualization support
On Mon, 27 May 2019 14:30:14 +0200
Halil Pasic <pasic at linux.ibm.com> wrote:
> On Mon, 27 May 2019 12:38:02 +0200
> Cornelia Huck <cohuck at redhat.com> wrote:
>
> > On Thu, 23 May 2019 18:22:04 +0200
> > Michael Mueller <mimu at linux.ibm.com> wrote:
> >
> > > From: Halil Pasic <pasic at linux.ibm.com>
> > >
> >
2020 Mar 03
1
[PATCH 0/2] virtio-blk: improve handling of DMA mapping failures
On Tue, Mar 03, 2020 at 03:12:52PM +0100, Halil Pasic wrote:
> On Thu, 13 Feb 2020 13:37:26 +0100
> Halil Pasic <pasic at linux.ibm.com> wrote:
>
> > Two patches are handling new edge cases introduced by doing DMA mappings
> > (which can fail) in virtio core.
> >
> > I stumbled upon this while stress testing I/O for Protected Virtual
> > Machines. I
2019 May 27
3
[PATCH v2 3/8] s390/cio: add basic protected virtualization support
On Thu, 23 May 2019 18:22:04 +0200
Michael Mueller <mimu at linux.ibm.com> wrote:
> From: Halil Pasic <pasic at linux.ibm.com>
>
> As virtio-ccw devices are channel devices, we need to use the dma area
> for any communication with the hypervisor.
>
> It handles neither QDIO in the common code, nor any device type specific
> stuff (like channel programs
2019 May 27
3
[PATCH v2 3/8] s390/cio: add basic protected virtualization support
On Thu, 23 May 2019 18:22:04 +0200
Michael Mueller <mimu at linux.ibm.com> wrote:
> From: Halil Pasic <pasic at linux.ibm.com>
>
> As virtio-ccw devices are channel devices, we need to use the dma area
> for any communication with the hypervisor.
>
> It handles neither QDIO in the common code, nor any device type specific
> stuff (like channel programs
2019 Nov 14
0
[PATCH 1/1] virtio_ring: fix return code on DMA mapping fails
Commit 780bc7903a32 ("virtio_ring: Support DMA APIs") makes
virtqueue_add() return -EIO when we fail to map our I/O buffers. This is
a very realistic scenario for guests with encrypted memory, as swiotlb
may run out of space, depending on it's size and the I/O load.
The virtio-blk driver interprets -EIO form virtqueue_add() as an IO
error, despite the fact that swiotlb full is in
2019 Jun 13
1
[PATCH v5 0/8] s390: virtio: support protected virtualization
On Thu, 13 Jun 2019 11:11:13 +0200
Michael Mueller <mimu at linux.ibm.com> wrote:
> Halil,
>
> I just ran my toleration tests successfully on current HW for
> this series.
>
> Michael
Thanks Michael! May I add a
Tested-by: Michael Mueller <mimu at linux.ibm.com>
for each patch?
>
> On 12.06.19 13:12, Halil Pasic wrote:
> > Enhanced virtualization
2019 Apr 26
33
[PATCH 00/10] s390: virtio: support protected virtualization
Enhanced virtualization protection technology may require the use of
bounce buffers for I/O. While support for this was built into the virtio
core, virtio-ccw wasn't changed accordingly.
Some background on technology (not part of this series) and the
terminology used.
* Protected Virtualization (PV):
Protected Virtualization guarantees, that non-shared memory of a guest
that operates in PV
2019 Apr 26
33
[PATCH 00/10] s390: virtio: support protected virtualization
Enhanced virtualization protection technology may require the use of
bounce buffers for I/O. While support for this was built into the virtio
core, virtio-ccw wasn't changed accordingly.
Some background on technology (not part of this series) and the
terminology used.
* Protected Virtualization (PV):
Protected Virtualization guarantees, that non-shared memory of a guest
that operates in PV
2019 May 13
4
[PATCH 06/10] s390/cio: add basic protected virtualization support
On Fri, 26 Apr 2019 20:32:41 +0200
Halil Pasic <pasic at linux.ibm.com> wrote:
> As virtio-ccw devices are channel devices, we need to use the dma area
> for any communication with the hypervisor.
>
> This patch addresses the most basic stuff (mostly what is required for
> virtio-ccw), and does take care of QDIO or any devices.
"does not take care of QDIO",