lkml.org 
[lkml]   [2024]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v18 064/121] KVM: TDX: Create initial guest memory
    From
    On Mon, Feb 26, 2024, Isaku Yamahata wrote:
    > On Thu, Feb 01, 2024 at 03:06:46PM -0800,
    > David Matlack <dmatlack@google.com> wrote:
    >
    > > +Vipin Sharma
    > >
    > > On Wed, Jan 31, 2024 at 4:21 PM Sean Christopherson <seanjc@google.com> wrote:
    > > > On Mon, Jan 22, 2024, isaku.yamahata@intel.com wrote:
    > > >
    > > > The real reason for this drive-by pseudo-review is that I am hoping/wishing we
    > > > can turn this into a generic KVM ioctl() to allow userspace to pre-map guest
    > > > memory[*].
    > > >
    > > > If we're going to carry non-trivial code, we might as well squeeze as much use
    > > > out of it as we can.
    > > >
    > > > Beyond wanting to shove this into KVM_MEMORY_ENCRYPT_OP, is there any reason why
    > > > this is a VM ioctl() and not a vCPU ioctl()? Very roughly, couldn't we use a
    > > > struct like this as input to a vCPU ioctl() that maps memory, and optionally
    > > > initializes memory from @source?
    > > >
    > > > struct kvm_memory_mapping {
    > > > __u64 base_gfn;
    > > > __u64 nr_pages;
    > > > __u64 flags;
    > > > __u64 source;
    > > > }
    > > >
    > > > TDX would need to do special things for copying the source, but beyond that most
    > > > of the code in this function is generic.
    > > >
    > > > [*] https://lore.kernel.org/all/65262e67-7885-971a-896d-ad9c0a760907@polito.it
    > >
    > > We would also be interested in such an API to reduce the guest
    > > performance impact of intra-host migration.
    >
    > I introduce KVM_MEMORY_MAPPING and KVM_CAP_MEMORY_MAPPING with v19.

    KVM_MEMORY_MAPPING is not a good ioctl() name. There needs to be a verb in there
    somewhere, e.g. KVM_MAP_MEMORY, KVM_FAULTIN_MEMORY, etc.

    > We can continue the discussion there.

    No, we absolutely cannot continue the conversation there. That is not how kernel
    development works.

    Enough is enough. I am archiving v19 and not touching it.

    Please post an RFC for _just_ this functionality, and follow-up in existing,
    pre-v19 conversations for anything else that changed between v18 and v19 and might
    need additional input/discussion.

    \
     
     \ /
      Last update: 2024-05-27 15:22    [W:2.591 / U:0.972 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site