qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 01/15] ide: add limit to .prepare_buf()


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2 01/15] ide: add limit to .prepare_buf()
Date: Thu, 2 Jul 2015 15:04:55 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Jul 01, 2015 at 12:19:24PM -0400, John Snow wrote:
> prepare_buf should not always grab as many descriptors
> as it can, sometimes it should self-limit.
> 
> For example, an NCQ transfer of 1 sector with a PRDT that
> describes 4GiB of data should not copy 4GiB of data, it
> should just transfer that first 512 bytes.
> 
> PIO is not affected, because the dma_buf_rw dma helpers
> already have a byte limit built-in to them, but DMA/NCQ
> will exhaust the entire list regardless of requested size.
> 
> AHCI 1.3 specifies in section 6.1.6 Command List Underflow that
> NCQ is not required to detect underflow conditions. Non-NCQ
> pathways signal underflow by writing to the PRDBC field, which
> will already occur by writing the actual transferred byte count
> to the PRDBC, signaling the underflow.
> 
> Our NCQ pathways aren't required to detect underflow, but since our DMA
> backend uses the size of the PRDT to determine the size of the transer,
> if our PRDT is bigger than the transaction (the underflow condition) it
> doesn't cost us anything to detect it and truncate the PRDT.
> 
> This is a recoverable error and is not signaled to the guest, in either
> NCQ or normal DMA cases.
> 
> For BMDMA, the existing pathways should see no guest-visible difference,
> but any bytes described in the overage will no longer be transferred
> before indicating to the guest that there was an underflow.
> 
> Signed-off-by: John Snow <address@hidden>
> ---
>  hw/ide/ahci.c     | 27 ++++++++++++++-------------
>  hw/ide/core.c     |  8 ++++----
>  hw/ide/internal.h |  2 +-
>  hw/ide/macio.c    |  2 +-
>  hw/ide/pci.c      | 21 ++++++++++++++++-----
>  5 files changed, 36 insertions(+), 24 deletions(-)

Reviewed-by: Stefan Hajnoczi <address@hidden>

Attachment: pgpT7csPEqr9Q.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]