On Wed, Nov 16, 2022, Andy Lutomirski wrote:

On Tue, Oct 25, 2022, at 8:13 AM, Chao Peng wrote:

quoted

diff --git a/Documentation/virt/kvm/api.rst 

b/Documentation/virt/kvm/api.rst
index f3fa75649a78..975688912b8c 100644

--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst

@@ -6537,6 +6537,29 @@ array field represents return values. The 

userspace should update the return
 values of SBI call before resuming the VCPU. For more details on 
RISC-V SBI
 spec refer, https://github.com/riscv/riscv-sbi-doc.

+::
+
+		/* KVM_EXIT_MEMORY_FAULT */
+		struct {
+  #define KVM_MEMORY_EXIT_FLAG_PRIVATE	(1 << 0)
+			__u32 flags;
+			__u32 padding;
+			__u64 gpa;
+			__u64 size;
+		} memory;
+

Would it make sense to also have a field for the access type (read, write,
execute, etc)?  I realize that shared <-> private conversion doesn't strictly
need this, but it seems like it could be useful for logging failures and also
for avoiding a second immediate fault if the type gets converted but doesn't
have the right protection yet.

I don't think a separate field is necessary, that info can be conveyed via flags.
Though maybe we should go straight to a u64 for flags.  Hmm, and maybe avoid bits
0-3 so that if/when RWX info is conveyed the flags can align with
PROT_{READ,WRITE,EXEC} and the EPT flags, e.g.

	KVM_MEMORY_EXIT_FLAG_READ	(1 << 0)
	KVM_MEMORY_EXIT_FLAG_WRITE	(1 << 1)
	KVM_MEMORY_EXIT_FLAG_EXECUTE	(1 << 2)

(Obviously, if this were changed, KVM would need the ability to report that
it doesn't actually know the mode.)

--Andy