Re: [Qemu-devel] [edk2] EDKII OVMF+QEMU Query- What is the Max supported Buffer size for file IO.

[Laszlo Ersek]

On 02/04/13 17:22, baban devkate wrote:
> 
>   When Working with OVMF+QEMU, What is the Max supported
>   Buffer size (in Block I/O Protocol)?

Are you producing EFI_BLOCK_IO_PROTOCOL, or consuming it?

If producing (ie. implementing a driver), then why does it matter?

BufferSize should be an integral multiple of
EFI_BLOCK_IO_MEDIA.BlockSize (you should check that condition and return
EFI_BAD_BUFFER_SIZE if it's violated). Also check that the end of the
full request doesn't fall of the end of the device, and whatever else
the spec says. Then you'd run a loop, transferring one block per iteration.

(In VirtioBlkDxe I limited individual requests to 1 GB, and didn't
bother to split bigger ones into loops -- I refuse those. The same limit
holds for VirtioScsiDxe per transfer, both directions combined.)

For performance I think you can fiddle with
LogicalBlocksPerPhysicalBlock / OptimalTransferLengthGranularity, but
that should only affect how the caller (BlockIo protocol consumer)
organizes its requests.

Respectively, if you're consuming the protocol, you might want to
consider LogicalBlocksPerPhysicalBlock /
OptimalTransferLengthGranularity for performance (if the protocol
revision supports those), but otherwise I think any sane request fitting
the media & being a multiple of the block size should work (supposing of
course that you managed to allocate a sufficiently big contiguous buffer).

- IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe seems to set a block size of
512 (0x200) for IDE disks, and 2048 (0x800) for IDE CD-ROMs.

- MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c does the same (... it
seems to interrogate the device but then overrides the result for disk &
cdrom... strange).

Laszlo