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

[Eric Auger]

Hi Peter,

On 2/8/22 6:14 PM, Peter Maydell wrote:
> 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.
CRB can work in passthrough mode though, although I don't know the
underlying implementation.

As mentionned in the other email

https://trustedcomputinggroup.org/wp-content/uploads/Mobile-Command-Response-Buffer-Interface-v2-r12-Specification_FINAL2.pdf
says

"
Including the control structure, the three memory areas comprise the
entirety of the CRB. There are no constraints on how those three memory
areas are provided. They can all be in system RAM, or all be in device
memory, or any combination.



>
>> 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...
Assuming that obviously makes things simpler and remove a bunch of
checks & error reports in vfio :) But wouldn' we silence some actual
dma-map failures we properly detect & report today?

Thanks

Eric
>
> thanks
> -- PMM
>