On Tue, 8 Feb 2022 at 16:36, Alex Williamson <[email protected]> wrote: > > On Tue, 8 Feb 2022 16:01:48 +0000 > Peter Maydell <[email protected]> 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
