Re: [PATCH, v2] physmem: avoid bounce buffer too small

[Peter Maydell]

On Thu, 29 Feb 2024 at 14:17, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 29.02.24 13:34, Peter Maydell wrote:
> > On Thu, 29 Feb 2024 at 11:17, Heinrich Schuchardt
> > <heinrich.schuchardt@canonical.com> wrote:
> >>> But yes, I'm not surprised that CXL runs into this. Heinrich,
> >>> are you doing CXL testing, or is this some other workload?
> >>
> >> I am running the UEFI Self-Certification Tests (SCT) on EDK 2 using:
> >>
> >> qemu-system-riscv64 \
> >>         -M virt,acpi=off -accel tcg -m 4096 \
> >>         -serial mon:stdio \
> >>         -device virtio-gpu-pci \
> >>         -device qemu-xhci \
> >>         -device usb-kbd \
> >>         -drive
> >> if=pflash,format=raw,unit=0,file=RISCV_VIRT_CODE.fd,readonly=on \
> >>         -drive if=pflash,format=raw,unit=1,file=RISCV_VIRT_VARS.fd \
> >>         -drive file=sct.img,format=raw,if=virtio \
> >>         -device virtio-net-device,netdev=net0 \
> >>         -netdev user,id=net0
> >>
> >> This does not invoke any CXL related stuff.
> >
> > Hmm, that doesn't seem like it ought to be running into this.
> > What underlying memory region is the guest trying to do
> > the virtio queue access to?

> The error occurs while the SCT is executing function
> BBTestReadBlocksConformanceAutoTest
> (https://github.com/tianocore/edk2-test/blob/cabb98d44be94e7547605435a0be7c4946d10f8b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/BlockIo/BlackBoxTest/BlockIoBBTestConformance.c#L45)
>
> This code is accessing the drive defined as
> -drive file=sct.img,format=raw,if=virtio .
>
> In the conformance test correct error handling for invalid parameters of
> the UEFI block IO protocol is tested. This includes calling the UEFI API to
>
> * read with incorrectly aligned buffers
> * read with invalid LBA parameter
> * read with buffer size not being a multiple of the sector size
>
> In all these cases the UEFI API implemented by EDK II is expected to
> return an error.

OK, but where is it actually reading/writing to ? Even if the
buffer isn't aligned right it ought not to be in a non-host-ram-backed
memory region, I would have thought.

-- PMM