diff for duplicates of <ZNKv9ul2I7A4V7IF@google.com> diff --git a/a/1.txt b/N1/1.txt index 97b08b2..5520092 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,13 +1,13 @@ On Mon, Aug 07, 2023, Ackerley Tng wrote: -> I?d like to propose an alternative to the refcounting approach between -> the gmem file and associated kvm, where we think of KVM?s memslots as +> I’d like to propose an alternative to the refcounting approach between +> the gmem file and associated kvm, where we think of KVM’s memslots as > users of the gmem file. > > Instead of having the gmem file pin the VM (i.e. take a refcount on > kvm), we could let memslot take a refcount on the gmem file when the > memslots are configured. > -> Here?s a POC patch that flips the refcounting (and modified selftests in +> Here’s a POC patch that flips the refcounting (and modified selftests in > the next commit): > https://github.com/googleprodkernel/linux-cc/commit/7f487b029b89b9f3e9b094a721bc0772f3c8c797 > @@ -44,7 +44,7 @@ that we want to allow that, or that it has desirable properties. With TDX and SNP in particuarly, I'm pretty sure that allowing memory to outlive the VM is very underisable (more below). -> The KVM pointer is shared among all the bindings in gmem?s xarray, and we can +> The KVM pointer is shared among all the bindings in gmem’s xarray, and we can > enforce that a gmem file is used only with one VM: > > + When binding a memslot to the file, if a kvm pointer exists, it must diff --git a/a/content_digest b/N1/content_digest index 5f30398..b583cda 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,21 +1,60 @@ "ref\020230718234512.1690985-13-seanjc@google.com\0" "ref\0diqzv8dq3116.fsf@ackerleytng-ctop.c.googlers.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0" + "Subject\0Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0" "Date\0Tue, 8 Aug 2023 14:13:26 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Ackerley Tng <ackerleytng@google.com>\0" + "Cc\0pbonzini@redhat.com" + maz@kernel.org + oliver.upton@linux.dev + chenhuacai@kernel.org + mpe@ellerman.id.au + anup@brainfault.org + paul.walmsley@sifive.com + palmer@dabbelt.com + aou@eecs.berkeley.edu + willy@infradead.org + akpm@linux-foundation.org + paul@paul-moore.com + jmorris@namei.org + serge@hallyn.com + kvm@vger.kernel.org + linux-arm-kernel@lists.infradead.org + kvmarm@lists.linux.dev + linux-mips@vger.kernel.org + linuxppc-dev@lists.ozlabs.org + kvm-riscv@lists.infradead.org + linux-riscv@lists.infradead.org + linux-fsdevel@vger.kernel.org + linux-mm@kvack.org + linux-security-module@vger.kernel.org + linux-kernel@vger.kernel.org + chao.p.peng@linux.intel.com + tabba@google.com + jarkko@kernel.org + yu.c.zhang@linux.intel.com + vannapurve@google.com + mail@maciej.szmigiero.name + vbabka@suse.cz + david@redhat.com + qperret@google.com + michael.roth@amd.com + wei.w.wang@intel.com + liam.merwick@oracle.com + isaku.yamahata@gmail.com + " kirill.shutemov@linux.intel.com\0" "\00:1\0" "b\0" "On Mon, Aug 07, 2023, Ackerley Tng wrote:\n" - "> I?d like to propose an alternative to the refcounting approach between\n" - "> the gmem file and associated kvm, where we think of KVM?s memslots as\n" + "> I\342\200\231d like to propose an alternative to the refcounting approach between\n" + "> the gmem file and associated kvm, where we think of KVM\342\200\231s memslots as\n" "> users of the gmem file.\n" "> \n" "> Instead of having the gmem file pin the VM (i.e. take a refcount on\n" "> kvm), we could let memslot take a refcount on the gmem file when the\n" "> memslots are configured.\n" "> \n" - "> Here?s a POC patch that flips the refcounting (and modified selftests in\n" + "> Here\342\200\231s a POC patch that flips the refcounting (and modified selftests in\n" "> the next commit):\n" "> https://github.com/googleprodkernel/linux-cc/commit/7f487b029b89b9f3e9b094a721bc0772f3c8c797\n" "> \n" @@ -52,7 +91,7 @@ "SNP in particuarly, I'm pretty sure that allowing memory to outlive the VM is\n" "very underisable (more below).\n" "\n" - "> The KVM pointer is shared among all the bindings in gmem?s xarray, and we can\n" + "> The KVM pointer is shared among all the bindings in gmem\342\200\231s xarray, and we can\n" "> enforce that a gmem file is used only with one VM:\n" "> \n" "> + When binding a memslot to the file, if a kvm pointer exists, it must\n" @@ -104,4 +143,4 @@ "well as the contract between KVM and userspace, and would break the separation of\n" concerns between the inode (physical memory / data) and file (VM's view / mappings). -0c938741905cd7d83edb9ccb6d170dd9a19f85767a7128cb6a762bb5ec5969f2 +eafac59f19285eab21cdeafd6380fc0c2216edac3a055b70b265b6a0ae672acf
diff --git a/a/1.txt b/N2/1.txt index 97b08b2..c85868b 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,13 +1,13 @@ On Mon, Aug 07, 2023, Ackerley Tng wrote: -> I?d like to propose an alternative to the refcounting approach between -> the gmem file and associated kvm, where we think of KVM?s memslots as +> I’d like to propose an alternative to the refcounting approach between +> the gmem file and associated kvm, where we think of KVM’s memslots as > users of the gmem file. > > Instead of having the gmem file pin the VM (i.e. take a refcount on > kvm), we could let memslot take a refcount on the gmem file when the > memslots are configured. > -> Here?s a POC patch that flips the refcounting (and modified selftests in +> Here’s a POC patch that flips the refcounting (and modified selftests in > the next commit): > https://github.com/googleprodkernel/linux-cc/commit/7f487b029b89b9f3e9b094a721bc0772f3c8c797 > @@ -44,7 +44,7 @@ that we want to allow that, or that it has desirable properties. With TDX and SNP in particuarly, I'm pretty sure that allowing memory to outlive the VM is very underisable (more below). -> The KVM pointer is shared among all the bindings in gmem?s xarray, and we can +> The KVM pointer is shared among all the bindings in gmem’s xarray, and we can > enforce that a gmem file is used only with one VM: > > + When binding a memslot to the file, if a kvm pointer exists, it must @@ -95,3 +95,8 @@ After working through the flows, I think binding on-demand would simplify the refcounting (stating the obvious), but complicate the lifecycle of the memory as well as the contract between KVM and userspace, and would break the separation of concerns between the inode (physical memory / data) and file (VM's view / mappings). + +_______________________________________________ +linux-riscv mailing list +linux-riscv@lists.infradead.org +http://lists.infradead.org/mailman/listinfo/linux-riscv diff --git a/a/content_digest b/N2/content_digest index 5f30398..358f8f3 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,21 +1,60 @@ "ref\020230718234512.1690985-13-seanjc@google.com\0" "ref\0diqzv8dq3116.fsf@ackerleytng-ctop.c.googlers.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0" + "Subject\0Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0" "Date\0Tue, 8 Aug 2023 14:13:26 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Ackerley Tng <ackerleytng@google.com>\0" + "Cc\0pbonzini@redhat.com" + maz@kernel.org + oliver.upton@linux.dev + chenhuacai@kernel.org + mpe@ellerman.id.au + anup@brainfault.org + paul.walmsley@sifive.com + palmer@dabbelt.com + aou@eecs.berkeley.edu + willy@infradead.org + akpm@linux-foundation.org + paul@paul-moore.com + jmorris@namei.org + serge@hallyn.com + kvm@vger.kernel.org + linux-arm-kernel@lists.infradead.org + kvmarm@lists.linux.dev + linux-mips@vger.kernel.org + linuxppc-dev@lists.ozlabs.org + kvm-riscv@lists.infradead.org + linux-riscv@lists.infradead.org + linux-fsdevel@vger.kernel.org + linux-mm@kvack.org + linux-security-module@vger.kernel.org + linux-kernel@vger.kernel.org + chao.p.peng@linux.intel.com + tabba@google.com + jarkko@kernel.org + yu.c.zhang@linux.intel.com + vannapurve@google.com + mail@maciej.szmigiero.name + vbabka@suse.cz + david@redhat.com + qperret@google.com + michael.roth@amd.com + wei.w.wang@intel.com + liam.merwick@oracle.com + isaku.yamahata@gmail.com + " kirill.shutemov@linux.intel.com\0" "\00:1\0" "b\0" "On Mon, Aug 07, 2023, Ackerley Tng wrote:\n" - "> I?d like to propose an alternative to the refcounting approach between\n" - "> the gmem file and associated kvm, where we think of KVM?s memslots as\n" + "> I\342\200\231d like to propose an alternative to the refcounting approach between\n" + "> the gmem file and associated kvm, where we think of KVM\342\200\231s memslots as\n" "> users of the gmem file.\n" "> \n" "> Instead of having the gmem file pin the VM (i.e. take a refcount on\n" "> kvm), we could let memslot take a refcount on the gmem file when the\n" "> memslots are configured.\n" "> \n" - "> Here?s a POC patch that flips the refcounting (and modified selftests in\n" + "> Here\342\200\231s a POC patch that flips the refcounting (and modified selftests in\n" "> the next commit):\n" "> https://github.com/googleprodkernel/linux-cc/commit/7f487b029b89b9f3e9b094a721bc0772f3c8c797\n" "> \n" @@ -52,7 +91,7 @@ "SNP in particuarly, I'm pretty sure that allowing memory to outlive the VM is\n" "very underisable (more below).\n" "\n" - "> The KVM pointer is shared among all the bindings in gmem?s xarray, and we can\n" + "> The KVM pointer is shared among all the bindings in gmem\342\200\231s xarray, and we can\n" "> enforce that a gmem file is used only with one VM:\n" "> \n" "> + When binding a memslot to the file, if a kvm pointer exists, it must\n" @@ -102,6 +141,11 @@ "After working through the flows, I think binding on-demand would simplify the\n" "refcounting (stating the obvious), but complicate the lifecycle of the memory as\n" "well as the contract between KVM and userspace, and would break the separation of\n" - concerns between the inode (physical memory / data) and file (VM's view / mappings). + "concerns between the inode (physical memory / data) and file (VM's view / mappings).\n" + "\n" + "_______________________________________________\n" + "linux-riscv mailing list\n" + "linux-riscv@lists.infradead.org\n" + http://lists.infradead.org/mailman/listinfo/linux-riscv -0c938741905cd7d83edb9ccb6d170dd9a19f85767a7128cb6a762bb5ec5969f2 +f65e0dbfdea53b1f88ce7a8880a3a4c594e7c295e6878f4a347f113e74d3e3e6
diff --git a/a/1.txt b/N3/1.txt index 97b08b2..5520092 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -1,13 +1,13 @@ On Mon, Aug 07, 2023, Ackerley Tng wrote: -> I?d like to propose an alternative to the refcounting approach between -> the gmem file and associated kvm, where we think of KVM?s memslots as +> I’d like to propose an alternative to the refcounting approach between +> the gmem file and associated kvm, where we think of KVM’s memslots as > users of the gmem file. > > Instead of having the gmem file pin the VM (i.e. take a refcount on > kvm), we could let memslot take a refcount on the gmem file when the > memslots are configured. > -> Here?s a POC patch that flips the refcounting (and modified selftests in +> Here’s a POC patch that flips the refcounting (and modified selftests in > the next commit): > https://github.com/googleprodkernel/linux-cc/commit/7f487b029b89b9f3e9b094a721bc0772f3c8c797 > @@ -44,7 +44,7 @@ that we want to allow that, or that it has desirable properties. With TDX and SNP in particuarly, I'm pretty sure that allowing memory to outlive the VM is very underisable (more below). -> The KVM pointer is shared among all the bindings in gmem?s xarray, and we can +> The KVM pointer is shared among all the bindings in gmem’s xarray, and we can > enforce that a gmem file is used only with one VM: > > + When binding a memslot to the file, if a kvm pointer exists, it must diff --git a/a/content_digest b/N3/content_digest index 5f30398..6ebb5ac 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -1,21 +1,59 @@ "ref\020230718234512.1690985-13-seanjc@google.com\0" "ref\0diqzv8dq3116.fsf@ackerleytng-ctop.c.googlers.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0" + "Subject\0Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0" "Date\0Tue, 8 Aug 2023 14:13:26 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Ackerley Tng <ackerleytng@google.com>\0" + "Cc\0kvm@vger.kernel.org" + david@redhat.com + yu.c.zhang@linux.intel.com + linux-kernel@vger.kernel.org + linux-mm@kvack.org + chao.p.peng@linux.intel.com + linux-riscv@lists.infradead.org + isaku.yamahata@gmail.com + paul@paul-moore.com + maz@kernel.org + chenhuacai@kernel.org + jmorris@namei.org + willy@infradead.org + wei.w.wang@intel.com + tabba@google.com + jarkko@kernel.org + serge@hallyn.com + mail@maciej.szmigiero.name + aou@eecs.berkeley.edu + vbabka@suse.cz + michael.roth@amd.com + paul.walmsley@sifive.com + kvmarm@lists.linux.dev + linux-arm-kernel@lists.infradead.org + qperret@google.com + liam.merwick@oracle.com + linux-mips@vger.kernel.org + oliver.upton@linux.dev + linux-security-module@vger.kernel.org + palmer@dabbelt.com + kvm-riscv@lists.infradead.org + anup@brainfault.org + linux-fsdevel@vger.kernel.org + pbonzini@redhat.com + akpm@linux-foundation.org + vannapurve@google.com + linuxppc-dev@lists.ozlabs.org + " kirill.shutemov@linux.intel.com\0" "\00:1\0" "b\0" "On Mon, Aug 07, 2023, Ackerley Tng wrote:\n" - "> I?d like to propose an alternative to the refcounting approach between\n" - "> the gmem file and associated kvm, where we think of KVM?s memslots as\n" + "> I\342\200\231d like to propose an alternative to the refcounting approach between\n" + "> the gmem file and associated kvm, where we think of KVM\342\200\231s memslots as\n" "> users of the gmem file.\n" "> \n" "> Instead of having the gmem file pin the VM (i.e. take a refcount on\n" "> kvm), we could let memslot take a refcount on the gmem file when the\n" "> memslots are configured.\n" "> \n" - "> Here?s a POC patch that flips the refcounting (and modified selftests in\n" + "> Here\342\200\231s a POC patch that flips the refcounting (and modified selftests in\n" "> the next commit):\n" "> https://github.com/googleprodkernel/linux-cc/commit/7f487b029b89b9f3e9b094a721bc0772f3c8c797\n" "> \n" @@ -52,7 +90,7 @@ "SNP in particuarly, I'm pretty sure that allowing memory to outlive the VM is\n" "very underisable (more below).\n" "\n" - "> The KVM pointer is shared among all the bindings in gmem?s xarray, and we can\n" + "> The KVM pointer is shared among all the bindings in gmem\342\200\231s xarray, and we can\n" "> enforce that a gmem file is used only with one VM:\n" "> \n" "> + When binding a memslot to the file, if a kvm pointer exists, it must\n" @@ -104,4 +142,4 @@ "well as the contract between KVM and userspace, and would break the separation of\n" concerns between the inode (physical memory / data) and file (VM's view / mappings). -0c938741905cd7d83edb9ccb6d170dd9a19f85767a7128cb6a762bb5ec5969f2 +c8d490817cff0fe995bf0636b9141a5a630d73e58343d35575b3b110976b109a
diff --git a/a/1.txt b/N4/1.txt index 97b08b2..4d70210 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -1,13 +1,13 @@ On Mon, Aug 07, 2023, Ackerley Tng wrote: -> I?d like to propose an alternative to the refcounting approach between -> the gmem file and associated kvm, where we think of KVM?s memslots as +> I’d like to propose an alternative to the refcounting approach between +> the gmem file and associated kvm, where we think of KVM’s memslots as > users of the gmem file. > > Instead of having the gmem file pin the VM (i.e. take a refcount on > kvm), we could let memslot take a refcount on the gmem file when the > memslots are configured. > -> Here?s a POC patch that flips the refcounting (and modified selftests in +> Here’s a POC patch that flips the refcounting (and modified selftests in > the next commit): > https://github.com/googleprodkernel/linux-cc/commit/7f487b029b89b9f3e9b094a721bc0772f3c8c797 > @@ -44,7 +44,7 @@ that we want to allow that, or that it has desirable properties. With TDX and SNP in particuarly, I'm pretty sure that allowing memory to outlive the VM is very underisable (more below). -> The KVM pointer is shared among all the bindings in gmem?s xarray, and we can +> The KVM pointer is shared among all the bindings in gmem’s xarray, and we can > enforce that a gmem file is used only with one VM: > > + When binding a memslot to the file, if a kvm pointer exists, it must @@ -95,3 +95,8 @@ After working through the flows, I think binding on-demand would simplify the refcounting (stating the obvious), but complicate the lifecycle of the memory as well as the contract between KVM and userspace, and would break the separation of concerns between the inode (physical memory / data) and file (VM's view / mappings). + +_______________________________________________ +linux-arm-kernel mailing list +linux-arm-kernel@lists.infradead.org +http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/a/content_digest b/N4/content_digest index 5f30398..b5c1ebf 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -1,21 +1,60 @@ "ref\020230718234512.1690985-13-seanjc@google.com\0" "ref\0diqzv8dq3116.fsf@ackerleytng-ctop.c.googlers.com\0" "From\0Sean Christopherson <seanjc@google.com>\0" - "Subject\0[RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0" + "Subject\0Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory\0" "Date\0Tue, 8 Aug 2023 14:13:26 -0700\0" - "To\0kvm-riscv@lists.infradead.org\0" + "To\0Ackerley Tng <ackerleytng@google.com>\0" + "Cc\0pbonzini@redhat.com" + maz@kernel.org + oliver.upton@linux.dev + chenhuacai@kernel.org + mpe@ellerman.id.au + anup@brainfault.org + paul.walmsley@sifive.com + palmer@dabbelt.com + aou@eecs.berkeley.edu + willy@infradead.org + akpm@linux-foundation.org + paul@paul-moore.com + jmorris@namei.org + serge@hallyn.com + kvm@vger.kernel.org + linux-arm-kernel@lists.infradead.org + kvmarm@lists.linux.dev + linux-mips@vger.kernel.org + linuxppc-dev@lists.ozlabs.org + kvm-riscv@lists.infradead.org + linux-riscv@lists.infradead.org + linux-fsdevel@vger.kernel.org + linux-mm@kvack.org + linux-security-module@vger.kernel.org + linux-kernel@vger.kernel.org + chao.p.peng@linux.intel.com + tabba@google.com + jarkko@kernel.org + yu.c.zhang@linux.intel.com + vannapurve@google.com + mail@maciej.szmigiero.name + vbabka@suse.cz + david@redhat.com + qperret@google.com + michael.roth@amd.com + wei.w.wang@intel.com + liam.merwick@oracle.com + isaku.yamahata@gmail.com + " kirill.shutemov@linux.intel.com\0" "\00:1\0" "b\0" "On Mon, Aug 07, 2023, Ackerley Tng wrote:\n" - "> I?d like to propose an alternative to the refcounting approach between\n" - "> the gmem file and associated kvm, where we think of KVM?s memslots as\n" + "> I\342\200\231d like to propose an alternative to the refcounting approach between\n" + "> the gmem file and associated kvm, where we think of KVM\342\200\231s memslots as\n" "> users of the gmem file.\n" "> \n" "> Instead of having the gmem file pin the VM (i.e. take a refcount on\n" "> kvm), we could let memslot take a refcount on the gmem file when the\n" "> memslots are configured.\n" "> \n" - "> Here?s a POC patch that flips the refcounting (and modified selftests in\n" + "> Here\342\200\231s a POC patch that flips the refcounting (and modified selftests in\n" "> the next commit):\n" "> https://github.com/googleprodkernel/linux-cc/commit/7f487b029b89b9f3e9b094a721bc0772f3c8c797\n" "> \n" @@ -52,7 +91,7 @@ "SNP in particuarly, I'm pretty sure that allowing memory to outlive the VM is\n" "very underisable (more below).\n" "\n" - "> The KVM pointer is shared among all the bindings in gmem?s xarray, and we can\n" + "> The KVM pointer is shared among all the bindings in gmem\342\200\231s xarray, and we can\n" "> enforce that a gmem file is used only with one VM:\n" "> \n" "> + When binding a memslot to the file, if a kvm pointer exists, it must\n" @@ -102,6 +141,11 @@ "After working through the flows, I think binding on-demand would simplify the\n" "refcounting (stating the obvious), but complicate the lifecycle of the memory as\n" "well as the contract between KVM and userspace, and would break the separation of\n" - concerns between the inode (physical memory / data) and file (VM's view / mappings). + "concerns between the inode (physical memory / data) and file (VM's view / mappings).\n" + "\n" + "_______________________________________________\n" + "linux-arm-kernel mailing list\n" + "linux-arm-kernel@lists.infradead.org\n" + http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -0c938741905cd7d83edb9ccb6d170dd9a19f85767a7128cb6a762bb5ec5969f2 +42963397f0c5967eddc2f2c8fb65bcc4d3f64c0f1820e749503a2d51d2439110
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.