Message-ID: <20231030130504.16f486a2@canb.auug.org.au>
Date:   Mon, 30 Oct 2023 13:05:04 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Sean Christopherson <seanjc@...gle.com>,
        Christoffer Dall <cdall@...columbia.edu>,
        Marc Zyngier <maz@...nel.org>
Cc:     Ackerley Tng <ackerleytng@...gle.com>,
        Chao Peng <chao.p.peng@...ux.intel.com>,
        Isaku Yamahata <isaku.yamahata@...el.com>,
        Jing Zhang <jingzhangos@...gle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Michael Roth <michael.roth@....com>,
        Oliver Upton <oliver.upton@...ux.dev>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Yu Zhang <yu.c.zhang@...ux.intel.com>
Subject: linux-next: manual merge of the kvm-x86 tree with the kvm-arm tree

Hi all,

Today's linux-next merge of the kvm-x86 tree got a conflict in:

  Documentation/virt/kvm/api.rst

between commits:

  6656cda0f3b2 ("KVM: arm64: Document KVM_ARM_GET_REG_WRITABLE_MASKS")
  dafa493dd01d ("KVM: arm64: Document vCPU feature selection UAPIs")

from the kvm-arm tree and commits:

  8e555bf388af ("KVM: Introduce KVM_SET_USER_MEMORY_REGION2")
  e82df88abb18 ("KVM: Introduce per-page memory attributes")
  fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory")
  a2e4643a589a ("KVM: Add transparent hugepage support for dedicated guest memory")

from the kvm-x86 tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/virt/kvm/api.rst
index d75c9a7a7193,205b0c3020c2..000000000000
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@@ -6124,56 -6107,137 +6161,187 @@@ writes to the CNTVCT_EL0 and CNTPCT_EL
  interface. No error will be returned, but the resulting offset will not be
  applied.
  
 -4.139 KVM_SET_USER_MEMORY_REGION2
 +.. _KVM_ARM_GET_REG_WRITABLE_MASKS:
 +
 +4.139 KVM_ARM_GET_REG_WRITABLE_MASKS
 +-------------------------------------------
 +
 +:Capability: KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES
 +:Architectures: arm64
 +:Type: vm ioctl
 +:Parameters: struct reg_mask_range (in/out)
 +:Returns: 0 on success, < 0 on error
 +
 +
 +::
 +
 +        #define KVM_ARM_FEATURE_ID_RANGE	0
 +        #define KVM_ARM_FEATURE_ID_RANGE_SIZE	(3 * 8 * 8)
 +
 +        struct reg_mask_range {
 +                __u64 addr;             /* Pointer to mask array */
 +                __u32 range;            /* Requested range */
 +                __u32 reserved[13];
 +        };
 +
 +This ioctl copies the writable masks for a selected range of registers to
 +userspace.
 +
 +The ``addr`` field is a pointer to the destination array where KVM copies
 +the writable masks.
 +
 +The ``range`` field indicates the requested range of registers.
 +``KVM_CHECK_EXTENSION`` for the ``KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES``
 +capability returns the supported ranges, expressed as a set of flags. Each
 +flag's bit index represents a possible value for the ``range`` field.
 +All other values are reserved for future use and KVM may return an error.
 +
 +The ``reserved[13]`` array is reserved for future use and should be 0, or
 +KVM may return an error.
 +
 +KVM_ARM_FEATURE_ID_RANGE (0)
 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 +
 +The Feature ID range is defined as the AArch64 System register space with
 +op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}.
 +
 +The mask returned array pointed to by ``addr`` is indexed by the macro
 +``ARM64_FEATURE_ID_RANGE_IDX(op0, op1, crn, crm, op2)``, allowing userspace
 +to know what fields can be changed for the system register described by
 +``op0, op1, crn, crm, op2``. KVM rejects ID register values that describe a
 +superset of the features supported by the system.
 +
++4.140 KVM_SET_USER_MEMORY_REGION2
+ ---------------------------------
+ 
+ :Capability: KVM_CAP_USER_MEMORY2
+ :Architectures: all
+ :Type: vm ioctl
+ :Parameters: struct kvm_userspace_memory_region2 (in)
+ :Returns: 0 on success, -1 on error
+ 
+ KVM_SET_USER_MEMORY_REGION2 is an extension to KVM_SET_USER_MEMORY_REGION that
+ allows mapping guest_memfd memory into a guest.  All fields shared with
+ KVM_SET_USER_MEMORY_REGION identically.  Userspace can set KVM_MEM_PRIVATE in
+ flags to have KVM bind the memory region to a given guest_memfd range of
+ [guest_memfd_offset, guest_memfd_offset + memory_size].  The target guest_memfd
+ must point at a file created via KVM_CREATE_GUEST_MEMFD on the current VM, and
+ the target range must not be bound to any other memory region.  All standard
+ bounds checks apply (use common sense).
+ 
+ ::
+ 
+   struct kvm_userspace_memory_region2 {
+ 	__u32 slot;
+ 	__u32 flags;
+ 	__u64 guest_phys_addr;
+ 	__u64 memory_size; /* bytes */
+ 	__u64 userspace_addr; /* start of the userspace allocated memory */
+   __u64 guest_memfd_offset;
+ 	__u32 guest_memfd;
+ 	__u32 pad1;
+ 	__u64 pad2[14];
+   };
+ 
+ A KVM_MEM_PRIVATE region _must_ have a valid guest_memfd (private memory) and
+ userspace_addr (shared memory).  However, "valid" for userspace_addr simply
+ means that the address itself must be a legal userspace address.  The backing
+ mapping for userspace_addr is not required to be valid/populated at the time of
+ KVM_SET_USER_MEMORY_REGION2, e.g. shared memory can be lazily mapped/allocated
+ on-demand.
+ 
+ When mapping a gfn into the guest, KVM selects shared vs. private, i.e consumes
+ userspace_addr vs. guest_memfd, based on the gfn's KVM_MEMORY_ATTRIBUTE_PRIVATE
+ state.  At VM creation time, all memory is shared, i.e. the PRIVATE attribute
+ is '0' for all gfns.  Userspace can control whether memory is shared/private by
+ toggling KVM_MEMORY_ATTRIBUTE_PRIVATE via KVM_SET_MEMORY_ATTRIBUTES as needed.
+ 
 -4.140 KVM_SET_MEMORY_ATTRIBUTES
++4.141 KVM_SET_MEMORY_ATTRIBUTES
+ -------------------------------
+ 
+ :Capability: KVM_CAP_MEMORY_ATTRIBUTES
+ :Architectures: x86
+ :Type: vm ioctl
+ :Parameters: struct kvm_memory_attributes(in)
+ :Returns: 0 on success, <0 on error
+ 
+ KVM_SET_MEMORY_ATTRIBUTES allows userspace to set memory attributes for a range
+ of guest physical memory.
+ 
+ ::
+ 
+   struct kvm_memory_attributes {
+ 	__u64 address;
+ 	__u64 size;
+ 	__u64 attributes;
+ 	__u64 flags;
+   };
+ 
+   #define KVM_MEMORY_ATTRIBUTE_PRIVATE           (1ULL << 3)
+ 
+ The address and size must be page aligned.  The supported attributes can be
+ retrieved via ioctl(KVM_CHECK_EXTENSION) on KVM_CAP_MEMORY_ATTRIBUTES.  If
+ executed on a VM, KVM_CAP_MEMORY_ATTRIBUTES precisely returns the attributes
+ supported by that VM.  If executed at system scope, KVM_CAP_MEMORY_ATTRIBUTES
+ returns all attributes supported by KVM.  The only attribute defined at this
+ time is KVM_MEMORY_ATTRIBUTE_PRIVATE, which marks the associated gfn as being
+ guest private memory.
+ 
+ Note, there is no "get" API.  Userspace is responsible for explicitly tracking
+ the state of a gfn/page as needed.
+ 
+ The "flags" field is reserved for future extensions and must be '0'.
+ 
 -4.141 KVM_CREATE_GUEST_MEMFD
++4.142 KVM_CREATE_GUEST_MEMFD
+ ----------------------------
+ 
+ :Capability: KVM_CAP_GUEST_MEMFD
+ :Architectures: none
+ :Type: vm ioctl
+ :Parameters: struct struct kvm_create_guest_memfd(in)
+ :Returns: 0 on success, <0 on error
+ 
+ KVM_CREATE_GUEST_MEMFD creates an anonymous file and returns a file descriptor
+ that refers to it.  guest_memfd files are roughly analogous to files created
+ via memfd_create(), e.g. guest_memfd files live in RAM, have volatile storage,
+ and are automatically released when the last reference is dropped.  Unlike
+ "regular" memfd_create() files, guest_memfd files are bound to their owning
+ virtual machine (see below), cannot be mapped, read, or written by userspace,
+ and cannot be resized  (guest_memfd files do however support PUNCH_HOLE).
+ 
+ ::
+ 
+   struct kvm_create_guest_memfd {
+ 	__u64 size;
+ 	__u64 flags;
+ 	__u64 reserved[6];
+   };
+ 
+   #define KVM_GUEST_MEMFD_ALLOW_HUGEPAGE         (1ULL << 0)
+ 
+ Conceptually, the inode backing a guest_memfd file represents physical memory,
+ i.e. is coupled to the virtual machine as a thing, not to a "struct kvm".  The
+ file itself, which is bound to a "struct kvm", is that instance's view of the
+ underlying memory, e.g. effectively provides the translation of guest addresses
+ to host memory.  This allows for use cases where multiple KVM structures are
+ used to manage a single virtual machine, e.g. when performing intrahost
+ migration of a virtual machine.
+ 
+ KVM currently only supports mapping guest_memfd via KVM_SET_USER_MEMORY_REGION2,
+ and more specifically via the guest_memfd and guest_memfd_offset fields in
+ "struct kvm_userspace_memory_region2", where guest_memfd_offset is the offset
+ into the guest_memfd instance.  For a given guest_memfd file, there can be at
+ most one mapping per page, i.e. binding multiple memory regions to a single
+ guest_memfd range is not allowed (any number of memory regions can be bound to
+ a single guest_memfd file, but the bound ranges must not overlap).
+ 
+ If KVM_GUEST_MEMFD_ALLOW_HUGEPAGE is set in flags, KVM will attempt to allocate
+ and map hugepages for the guest_memfd file.  This is currently best effort.  If
+ KVM_GUEST_MEMFD_ALLOW_HUGEPAGE is set, the size must be aligned to the maximum
+ transparent hugepage size supported by the kernel
+ 
+ See KVM_SET_USER_MEMORY_REGION2 for additional details.
+ 
  5. The kvm_run structure
  ========================
  

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists