)]}'
{
  "commit": "5d6483edaa9232d8f3709f68c8eab4bc2033fb70",
  "tree": "e21582075e5449ffab1f285d7813f66549e405ff",
  "parents": [
    "2205b8466733f8c6e3306c964f31c5a7cac69dfa"
  ],
  "author": {
    "name": "Chenyi Qiang",
    "email": "chenyi.qiang@intel.com",
    "time": "Thu Jun 12 16:27:45 2025 +0800"
  },
  "committer": {
    "name": "Peter Xu",
    "email": "peterx@redhat.com",
    "time": "Mon Jun 23 16:03:59 2025 -0400"
  },
  "message": "ram-block-attributes: Introduce RamBlockAttributes to manage RAMBlock with guest_memfd\n\nCommit 852f0048f3 (\"RAMBlock: make guest_memfd require uncoordinated\ndiscard\") highlighted that subsystems like VFIO may disable RAM block\ndiscard. However, guest_memfd relies on discard operations for page\nconversion between private and shared memory, potentially leading to\nthe stale IOMMU mapping issue when assigning hardware devices to\nconfidential VMs via shared memory. To address this and allow shared\ndevice assignement, it is crucial to ensure the VFIO system refreshes\nits IOMMU mappings.\n\nRamDiscardManager is an existing interface (used by virtio-mem) to\nadjust VFIO mappings in relation to VM page assignment. Effectively page\nconversion is similar to hot-removing a page in one mode and adding it\nback in the other. Therefore, similar actions are required for page\nconversion events. Introduce the RamDiscardManager to guest_memfd to\nfacilitate this process.\n\nSince guest_memfd is not an object, it cannot directly implement the\nRamDiscardManager interface. Implementing it in HostMemoryBackend is\nnot appropriate because guest_memfd is per RAMBlock, and some RAMBlocks\nhave a memory backend while others do not. Notably, virtual BIOS\nRAMBlocks using memory_region_init_ram_guest_memfd() do not have a\nbackend.\n\nTo manage RAMBlocks with guest_memfd, define a new object named\nRamBlockAttributes to implement the RamDiscardManager interface. This\nobject can store the guest_memfd information such as the bitmap for\nshared memory and the registered listeners for event notifications. A\nnew state_change() helper function is provided to notify listeners, such\nas VFIO, allowing VFIO to do dynamically DMA map and unmap for the shared\nmemory according to conversion events. Note that in the current context\nof RamDiscardManager for guest_memfd, the shared state is analogous to\nbeing populated, while the private state can be considered discarded for\nsimplicity. In the future, it would be more complicated if considering\nmore states like private/shared/discarded at the same time.\n\nIn current implementation, memory state tracking is performed at the\nhost page size granularity, as the minimum conversion size can be one\npage per request. Additionally, VFIO expected the DMA mapping for a\nspecific IOVA to be mapped and unmapped with the same granularity.\nConfidential VMs may perform partial conversions, such as conversions on\nsmall regions within a larger one. To prevent such invalid cases and\nuntil support for DMA mapping cut operations is available, all\noperations are performed with 4K granularity.\n\nIn addition, memory conversion failures cause QEMU to quit rather than\nresuming the guest or retrying the operation at present. It would be\nfuture work to add more error handling or rollback mechanisms once\nconversion failures are allowed. For example, in-place conversion of\nguest_memfd could retry the unmap operation during the conversion from\nshared to private. For now, keep the complex error handling out of the\npicture as it is not required.\n\nTested-by: Alexey Kardashevskiy \u003caik@amd.com\u003e\nReviewed-by: Alexey Kardashevskiy \u003caik@amd.com\u003e\nReviewed-by: Pankaj Gupta \u003cpankaj.gupta@amd.com\u003e\nSigned-off-by: Chenyi Qiang \u003cchenyi.qiang@intel.com\u003e\nLink: https://lore.kernel.org/r/20250612082747.51539-5-chenyi.qiang@intel.com\n[peterx: squash fixup from Chenyi to fix builds]\nSigned-off-by: Peter Xu \u003cpeterx@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "94c40761278208abae1a93d6b6c8ffcde6bfe817",
      "old_mode": 33188,
      "old_path": "MAINTAINERS",
      "new_id": "27f4fe3f2597cb9b5a28d825e965ed891e15d4f2",
      "new_mode": 33188,
      "new_path": "MAINTAINERS"
    },
    {
      "type": "modify",
      "old_id": "d8a116ba99343354ff307d0720284611a54da2d1",
      "old_mode": 33188,
      "old_path": "include/system/ramblock.h",
      "new_id": "1bab9e2dacea5d78d4de20411672996b3a5e30e4",
      "new_mode": 33188,
      "new_path": "include/system/ramblock.h"
    },
    {
      "type": "modify",
      "old_id": "7514bf3455d579fc50aae344f7d46534809a593f",
      "old_mode": 33188,
      "old_path": "system/meson.build",
      "new_id": "6d21ff9faa7f7cebd812e74b3e2c908478bddbc7",
      "new_mode": 33188,
      "new_path": "system/meson.build"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "68e8a02703235357d1dd62aaf38b57de9c2a1577",
      "new_mode": 33188,
      "new_path": "system/ram-block-attributes.c"
    },
    {
      "type": "modify",
      "old_id": "be12ebfb4189e2fa3f87e89d08f729b2cf54ac84",
      "old_mode": 33188,
      "old_path": "system/trace-events",
      "new_id": "82856e44f2e19a0348c1e58186ac4c19be8d51a9",
      "new_mode": 33188,
      "new_path": "system/trace-events"
    }
  ]
}