Re: [PATCH v4 1/2] tpm: CRB: Use ram_device for "tpm-crb-cmd" region

[Peter Maydell]

On Tue, 8 Feb 2022 at 16:36, Alex Williamson <alex.williamson@redhat.com> wrote:
>
> On Tue, 8 Feb 2022 16:01:48 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
> > Well, it can if it likes, but "this is a RAM-backed MemoryRegion"
> > doesn't imply "this is really guest actual RAM RAM", so if it's
> > using that as its discriminator it should probably use something else.
> > What is it actually trying to do here ?
>
> VFIO is device agnostic, we don't understand the device programming
> model, we can't know how the device is programmed to perform DMA.  The
> only way we can provide transparent assignment of arbitrary PCI devices
> is to install DMA mappings for everything in the device AddressSpace
> through the system IOMMU.  If we were to get a sub-page RAM mapping
> through the MemoryListener and that mapping had the possibility of
> being a DMA target, then we have a problem, because we cannot represent
> that through the IOMMU.  If the device were to use that address for DMA,
> we'd likely have data loss/corruption in the VM.

This is true whether that small MR is RAM-backed or MMIO-backed
or RAM-backed and marked as being a "ram device", though,
isn't it ?

> AFAIK, and I thought we had some general agreement on this, declaring
> device memory as ram_device is the only means we have to differentiate
> MemoryRegion segments generated by a device from actual system RAM.

What do you mean by "generated by a device" here? Devices within
QEMU create MemoryRegions of all kinds; some of them are RAM-backed,
some of them are not.

memory_region_init_ram_device_ptr() is (per the documentation)
for when the backing device is a real host device that vfio is
wrapping to turn into a QEMU device.

tpm_crb is not a real host device, though -- it's an actually
emulated-by-QEMU device.

> For device memory, we can lean on the fact that peer-to-peer DMA is
> much more rare and likely involves some degree of validation by the
> drivers since it can be blocked on physical hardware due to various
> topology and chipset related issues.  Therefore we can consider
> failures to map device memory at a lower risk than failures to map
> ranges we think are actual system RAM.

Well, if it's not page aligned and at least page sized it's
a pretty reasonable guess that it's not system RAM...

thanks
-- PMM