aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/generate_rust_analyzer.py
diff options
context:
space:
mode:
authorOliver Upton <oliver.upton@linux.dev>2024-03-07 00:56:01 +0000
committerOliver Upton <oliver.upton@linux.dev>2024-03-07 00:56:01 +0000
commit9bd8d7df1971c2ebdcaf4526cf7a3f4ea38d0ede (patch)
tree1a773f15a68befda40169b1a8432742909d2b3f3 /scripts/generate_rust_analyzer.py
parentMerge branch kvm-arm64/lpi-xarray into kvmarm/next (diff)
parentvfio: Convey kvm that the vfio-pci device is wc safe (diff)
downloadlinux-rng-9bd8d7df1971c2ebdcaf4526cf7a3f4ea38d0ede.tar.xz
linux-rng-9bd8d7df1971c2ebdcaf4526cf7a3f4ea38d0ede.zip
Merge branch kvm-arm64/vfio-normal-nc into kvmarm/next
* kvm-arm64/vfio-normal-nc: : Normal-NC support for vfio-pci @ stage-2, courtesy of Ankit Agrawal : : KVM's policy to date has been that any and all MMIO mapping at stage-2 : is treated as Device-nGnRE. This is primarily done due to concerns of : the guest triggering uncontainable failures in the system if they manage : to tickle the device / memory system the wrong way, though this is : unnecessarily restrictive for devices that can be reasoned as 'safe'. : : Unsurprisingly, the Device-* mapping can really hurt the performance of : assigned devices that can handle Gathering, and can be an outright : correctness issue if the guest driver does unaligned accesses. : : Rather than opening the floodgates to the full ecosystem of devices that : can be exposed to VMs, take the conservative approach and allow PCI : devices to be mapped as Normal-NC since it has been determined to be : 'safe'. vfio: Convey kvm that the vfio-pci device is wc safe KVM: arm64: Set io memory s2 pte as normalnc for vfio pci device mm: Introduce new flag to indicate wc safe KVM: arm64: Introduce new flag for non-cacheable IO memory Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Diffstat (limited to 'scripts/generate_rust_analyzer.py')
0 files changed, 0 insertions, 0 deletions