On 2021/2/9 下午10:59, Stefan Hajnoczi wrote:
On Mon, Feb 08, 2021 at 02:21:35PM +0800, Jason Wang wrote:
On 2021/1/30 上午2:48, Elena Afanasova wrote:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index ca41220b40b8..81e775778c66 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -732,6 +732,27 @@ struct kvm_ioeventfd {
__u8 pad[36];
};
+enum {
+ kvm_ioregion_flag_nr_pio,
+ kvm_ioregion_flag_nr_posted_writes,
+ kvm_ioregion_flag_nr_max,
+};
+
+#define KVM_IOREGION_PIO (1 << kvm_ioregion_flag_nr_pio)
+#define KVM_IOREGION_POSTED_WRITES (1 << kvm_ioregion_flag_nr_posted_writes)
+
+#define KVM_IOREGION_VALID_FLAG_MASK ((1 << kvm_ioregion_flag_nr_max) - 1)
+
+struct kvm_ioregion {
+ __u64 guest_paddr; /* guest physical address */
+ __u64 memory_size; /* bytes */
Do we really need __u64 here?
I think 64-bit PCI BARs can be >4 GB. There is plenty of space in this
struct to support a 64-bit field.
That said, userspace could also add more ioregions if it needs to cover
more than 4 GB. That would slow down ioregion lookups though since the
in-kernel data structure would become larger.
Making it 64-bit seems more future-proof and cleaner than having to work
around the limitation using multiple ioregions. Did you have a
particular reason in mind why this field should not be 64 bits?
Nope. Just wonder what's the use case for that.
Thanks
