From: Sean Christopherson <seanjc@google.com>
To: Elliot Berman <quic_eberman@quicinc.com>
Cc: Ackerley Tng <ackerleytng@google.com>,
pbonzini@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
Subject: Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
Date: Thu, 14 Sep 2023 12:12:14 -0700 [thread overview]
Message-ID: <ZQNbDt6vqwC4gZmi@google.com> (raw)
In-Reply-To: <253965df-6d80-bbfd-ab01-f9e69b274bf3@quicinc.com>
On Mon, Aug 28, 2023, Elliot Berman wrote:
> I had a 3rd question that's related to how to wire the gmem up to a virtual
> machine:
>
> I learned of a usecase to implement copy-on-write for gmem. The premise
> would be to have a "golden copy" of the memory that multiple virtual
> machines can map in as RO. If a virtual machine tries to write to those
> pages, they get copied to a virtual machine-specific page that isn't shared
> with other VMs. How do we track those pages?
The answer is going to be gunyah specific, because gmem itself isn't designed to
provide a virtualization layer ("virtual" in the virtual memory sense, not in the
virtual machine sense). Like any other CoW implementation, the RO page would need
to be copied to a different physical page, and whatever layer translates gfns
to physical pages would need to be updated. E.g. in gmem terms, allocate a new
gmem page/instance and update the gfn=>gmem[offset] translation in KVM/gunyah.
For VMA-based memory, that translation happens in the primary MMU, and is largely
transparent to KVM (or any other secondary MMU). E.g. the primary MMU works with
the backing store (if necessary) to allocate a new page and do the copy, notifies
secondary MMUs, zaps the old PTE(s), and then installs the new PTE(s). KVM/gunyah
just needs to react to the mmu_notifier event, e.g. zap secondary MMU PTEs, and
then KVM/gunyah naturally gets the new, writable page/PTE when following the host
virtual address, e.g. via gup().
The downside of eliminating the middle-man (primary MMU) from gmem is that the
"owner" (KVM or gunyah) is now responsible for these types of operations. For some
things, e.g. page migration, it's actually easier in some ways, but for CoW it's
quite a bit more work for KVM/gunyah because KVM/gunyah now needs to do things
that were previously handled by the primary MMU.
In KVM, assuming no additional support in KVM, doing CoW would mean modifying
memslots to redirect the gfn from the RO page to the writable page. For a variety
of reasons, that would be _extremely_ expensive in KVM, but still possible. If
there were a strong use case for supporting CoW with KVM+gmem, then I suspect that
we'd probably implement new KVM uAPI of some form to provide reasonable performance.
But I highly doubt we'll ever do that, because one of core tenets of KVM+gmem is
to isolate guest memory from the rest of the world, and especially from host
userspace, and that just doesn't mesh well with CoW'd memory being shared across
multiple VMs.
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Elliot Berman <quic_eberman@quicinc.com>
Cc: Ackerley Tng <ackerleytng@google.com>,
pbonzini@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
Subject: Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
Date: Thu, 14 Sep 2023 12:12:14 -0700 [thread overview]
Message-ID: <ZQNbDt6vqwC4gZmi@google.com> (raw)
In-Reply-To: <253965df-6d80-bbfd-ab01-f9e69b274bf3@quicinc.com>
On Mon, Aug 28, 2023, Elliot Berman wrote:
> I had a 3rd question that's related to how to wire the gmem up to a virtual
> machine:
>
> I learned of a usecase to implement copy-on-write for gmem. The premise
> would be to have a "golden copy" of the memory that multiple virtual
> machines can map in as RO. If a virtual machine tries to write to those
> pages, they get copied to a virtual machine-specific page that isn't shared
> with other VMs. How do we track those pages?
The answer is going to be gunyah specific, because gmem itself isn't designed to
provide a virtualization layer ("virtual" in the virtual memory sense, not in the
virtual machine sense). Like any other CoW implementation, the RO page would need
to be copied to a different physical page, and whatever layer translates gfns
to physical pages would need to be updated. E.g. in gmem terms, allocate a new
gmem page/instance and update the gfn=>gmem[offset] translation in KVM/gunyah.
For VMA-based memory, that translation happens in the primary MMU, and is largely
transparent to KVM (or any other secondary MMU). E.g. the primary MMU works with
the backing store (if necessary) to allocate a new page and do the copy, notifies
secondary MMUs, zaps the old PTE(s), and then installs the new PTE(s). KVM/gunyah
just needs to react to the mmu_notifier event, e.g. zap secondary MMU PTEs, and
then KVM/gunyah naturally gets the new, writable page/PTE when following the host
virtual address, e.g. via gup().
The downside of eliminating the middle-man (primary MMU) from gmem is that the
"owner" (KVM or gunyah) is now responsible for these types of operations. For some
things, e.g. page migration, it's actually easier in some ways, but for CoW it's
quite a bit more work for KVM/gunyah because KVM/gunyah now needs to do things
that were previously handled by the primary MMU.
In KVM, assuming no additional support in KVM, doing CoW would mean modifying
memslots to redirect the gfn from the RO page to the writable page. For a variety
of reasons, that would be _extremely_ expensive in KVM, but still possible. If
there were a strong use case for supporting CoW with KVM+gmem, then I suspect that
we'd probably implement new KVM uAPI of some form to provide reasonable performance.
But I highly doubt we'll ever do that, because one of core tenets of KVM+gmem is
to isolate guest memory from the rest of the world, and especially from host
userspace, and that just doesn't mesh well with CoW'd memory being shared across
multiple VMs.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Elliot Berman <quic_eberman@quicinc.com>
Cc: kvm@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,
Ackerley Tng <ackerleytng@google.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
Subject: Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
Date: Thu, 14 Sep 2023 12:12:14 -0700 [thread overview]
Message-ID: <ZQNbDt6vqwC4gZmi@google.com> (raw)
In-Reply-To: <253965df-6d80-bbfd-ab01-f9e69b274bf3@quicinc.com>
On Mon, Aug 28, 2023, Elliot Berman wrote:
> I had a 3rd question that's related to how to wire the gmem up to a virtual
> machine:
>
> I learned of a usecase to implement copy-on-write for gmem. The premise
> would be to have a "golden copy" of the memory that multiple virtual
> machines can map in as RO. If a virtual machine tries to write to those
> pages, they get copied to a virtual machine-specific page that isn't shared
> with other VMs. How do we track those pages?
The answer is going to be gunyah specific, because gmem itself isn't designed to
provide a virtualization layer ("virtual" in the virtual memory sense, not in the
virtual machine sense). Like any other CoW implementation, the RO page would need
to be copied to a different physical page, and whatever layer translates gfns
to physical pages would need to be updated. E.g. in gmem terms, allocate a new
gmem page/instance and update the gfn=>gmem[offset] translation in KVM/gunyah.
For VMA-based memory, that translation happens in the primary MMU, and is largely
transparent to KVM (or any other secondary MMU). E.g. the primary MMU works with
the backing store (if necessary) to allocate a new page and do the copy, notifies
secondary MMUs, zaps the old PTE(s), and then installs the new PTE(s). KVM/gunyah
just needs to react to the mmu_notifier event, e.g. zap secondary MMU PTEs, and
then KVM/gunyah naturally gets the new, writable page/PTE when following the host
virtual address, e.g. via gup().
The downside of eliminating the middle-man (primary MMU) from gmem is that the
"owner" (KVM or gunyah) is now responsible for these types of operations. For some
things, e.g. page migration, it's actually easier in some ways, but for CoW it's
quite a bit more work for KVM/gunyah because KVM/gunyah now needs to do things
that were previously handled by the primary MMU.
In KVM, assuming no additional support in KVM, doing CoW would mean modifying
memslots to redirect the gfn from the RO page to the writable page. For a variety
of reasons, that would be _extremely_ expensive in KVM, but still possible. If
there were a strong use case for supporting CoW with KVM+gmem, then I suspect that
we'd probably implement new KVM uAPI of some form to provide reasonable performance.
But I highly doubt we'll ever do that, because one of core tenets of KVM+gmem is
to isolate guest memory from the rest of the world, and especially from host
userspace, and that just doesn't mesh well with CoW'd memory being shared across
multiple VMs.
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Elliot Berman <quic_eberman@quicinc.com>
Cc: Ackerley Tng <ackerleytng@google.com>,
pbonzini@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
Subject: Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
Date: Thu, 14 Sep 2023 12:12:14 -0700 [thread overview]
Message-ID: <ZQNbDt6vqwC4gZmi@google.com> (raw)
In-Reply-To: <253965df-6d80-bbfd-ab01-f9e69b274bf3@quicinc.com>
On Mon, Aug 28, 2023, Elliot Berman wrote:
> I had a 3rd question that's related to how to wire the gmem up to a virtual
> machine:
>
> I learned of a usecase to implement copy-on-write for gmem. The premise
> would be to have a "golden copy" of the memory that multiple virtual
> machines can map in as RO. If a virtual machine tries to write to those
> pages, they get copied to a virtual machine-specific page that isn't shared
> with other VMs. How do we track those pages?
The answer is going to be gunyah specific, because gmem itself isn't designed to
provide a virtualization layer ("virtual" in the virtual memory sense, not in the
virtual machine sense). Like any other CoW implementation, the RO page would need
to be copied to a different physical page, and whatever layer translates gfns
to physical pages would need to be updated. E.g. in gmem terms, allocate a new
gmem page/instance and update the gfn=>gmem[offset] translation in KVM/gunyah.
For VMA-based memory, that translation happens in the primary MMU, and is largely
transparent to KVM (or any other secondary MMU). E.g. the primary MMU works with
the backing store (if necessary) to allocate a new page and do the copy, notifies
secondary MMUs, zaps the old PTE(s), and then installs the new PTE(s). KVM/gunyah
just needs to react to the mmu_notifier event, e.g. zap secondary MMU PTEs, and
then KVM/gunyah naturally gets the new, writable page/PTE when following the host
virtual address, e.g. via gup().
The downside of eliminating the middle-man (primary MMU) from gmem is that the
"owner" (KVM or gunyah) is now responsible for these types of operations. For some
things, e.g. page migration, it's actually easier in some ways, but for CoW it's
quite a bit more work for KVM/gunyah because KVM/gunyah now needs to do things
that were previously handled by the primary MMU.
In KVM, assuming no additional support in KVM, doing CoW would mean modifying
memslots to redirect the gfn from the RO page to the writable page. For a variety
of reasons, that would be _extremely_ expensive in KVM, but still possible. If
there were a strong use case for supporting CoW with KVM+gmem, then I suspect that
we'd probably implement new KVM uAPI of some form to provide reasonable performance.
But I highly doubt we'll ever do that, because one of core tenets of KVM+gmem is
to isolate guest memory from the rest of the world, and especially from host
userspace, and that just doesn't mesh well with CoW'd memory being shared across
multiple VMs.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-09-14 19:12 UTC|newest]
Thread overview: 517+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 23:44 [RFC PATCH v11 00/29] KVM: guest_memfd() and per-page attributes Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` [RFC PATCH v11 01/29] KVM: Wrap kvm_gfn_range.pte in a per-action union Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-19 13:39 ` Jarkko Sakkinen
2023-07-19 13:39 ` Jarkko Sakkinen
2023-07-19 13:39 ` Jarkko Sakkinen
2023-07-19 13:39 ` Jarkko Sakkinen
2023-07-19 15:39 ` Sean Christopherson
2023-07-19 15:39 ` Sean Christopherson
2023-07-19 15:39 ` Sean Christopherson
2023-07-19 15:39 ` Sean Christopherson
2023-07-19 16:55 ` Paolo Bonzini
2023-07-19 16:55 ` Paolo Bonzini
2023-07-19 16:55 ` Paolo Bonzini
2023-07-19 16:55 ` Paolo Bonzini
2023-07-26 20:22 ` Sean Christopherson
2023-07-26 20:22 ` Sean Christopherson
2023-07-26 20:22 ` Sean Christopherson
2023-07-21 6:26 ` Yan Zhao
2023-07-21 6:26 ` Yan Zhao
2023-07-21 6:26 ` Yan Zhao
2023-07-21 6:26 ` Yan Zhao
2023-07-21 10:45 ` Xu Yilun
2023-07-21 10:45 ` Xu Yilun
2023-07-21 10:45 ` Xu Yilun
2023-07-21 10:45 ` Xu Yilun
2023-07-25 18:05 ` Sean Christopherson
2023-07-25 18:05 ` Sean Christopherson
2023-07-25 18:05 ` Sean Christopherson
2023-07-18 23:44 ` [RFC PATCH v11 02/29] KVM: Tweak kvm_hva_range and hva_handler_t to allow reusing for gfn ranges Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-19 17:12 ` Paolo Bonzini
2023-07-19 17:12 ` Paolo Bonzini
2023-07-19 17:12 ` Paolo Bonzini
2023-07-19 17:12 ` Paolo Bonzini
2023-07-18 23:44 ` [RFC PATCH v11 03/29] KVM: Use gfn instead of hva for mmu_notifier_retry Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-19 17:12 ` Paolo Bonzini
2023-07-19 17:12 ` Paolo Bonzini
2023-07-19 17:12 ` Paolo Bonzini
2023-07-19 17:12 ` Paolo Bonzini
2023-07-18 23:44 ` [RFC PATCH v11 04/29] KVM: PPC: Drop dead code related to KVM_ARCH_WANT_MMU_NOTIFIER Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-19 17:34 ` Paolo Bonzini
2023-07-19 17:34 ` Paolo Bonzini
2023-07-19 17:34 ` Paolo Bonzini
2023-07-19 17:34 ` Paolo Bonzini
2023-07-18 23:44 ` [RFC PATCH v11 05/29] KVM: Convert KVM_ARCH_WANT_MMU_NOTIFIER to CONFIG_KVM_GENERIC_MMU_NOTIFIER Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-19 7:31 ` Yuan Yao
2023-07-19 7:31 ` Yuan Yao
2023-07-19 7:31 ` Yuan Yao
2023-07-19 7:31 ` Yuan Yao
2023-07-19 14:15 ` Sean Christopherson
2023-07-19 14:15 ` Sean Christopherson
2023-07-19 14:15 ` Sean Christopherson
2023-07-19 14:15 ` Sean Christopherson
2023-07-20 1:15 ` Yuan Yao
2023-07-20 1:15 ` Yuan Yao
2023-07-20 1:15 ` Yuan Yao
2023-07-20 1:15 ` Yuan Yao
2023-07-18 23:44 ` [RFC PATCH v11 06/29] KVM: Introduce KVM_SET_USER_MEMORY_REGION2 Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-21 9:03 ` Paolo Bonzini
2023-07-21 9:03 ` Paolo Bonzini
2023-07-21 9:03 ` Paolo Bonzini
2023-07-21 9:03 ` Paolo Bonzini
2023-07-28 9:25 ` Quentin Perret
2023-07-28 9:25 ` Quentin Perret
2023-07-28 9:25 ` Quentin Perret
2023-07-28 9:25 ` Quentin Perret
2023-07-29 0:03 ` Sean Christopherson
2023-07-29 0:03 ` Sean Christopherson
2023-07-29 0:03 ` Sean Christopherson
2023-07-29 0:03 ` Sean Christopherson
2023-07-31 9:30 ` Quentin Perret
2023-07-31 9:30 ` Quentin Perret
2023-07-31 9:30 ` Quentin Perret
2023-07-31 9:30 ` Quentin Perret
2023-07-31 15:58 ` Paolo Bonzini
2023-07-31 15:58 ` Paolo Bonzini
2023-07-31 15:58 ` Paolo Bonzini
2023-07-31 15:58 ` Paolo Bonzini
2023-07-18 23:44 ` [RFC PATCH v11 07/29] KVM: Add KVM_EXIT_MEMORY_FAULT exit Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-19 7:54 ` Yuan Yao
2023-07-19 7:54 ` Yuan Yao
2023-07-19 7:54 ` Yuan Yao
2023-07-19 7:54 ` Yuan Yao
2023-07-19 14:16 ` Sean Christopherson
2023-07-19 14:16 ` Sean Christopherson
2023-07-19 14:16 ` Sean Christopherson
2023-07-19 14:16 ` Sean Christopherson
2023-07-18 23:44 ` [RFC PATCH v11 08/29] KVM: Introduce per-page memory attributes Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-20 8:09 ` Yuan Yao
2023-07-20 8:09 ` Yuan Yao
2023-07-20 8:09 ` Yuan Yao
2023-07-20 8:09 ` Yuan Yao
2023-07-20 19:02 ` Isaku Yamahata
2023-07-20 19:02 ` Isaku Yamahata
2023-07-20 19:02 ` Isaku Yamahata
2023-07-20 19:02 ` Isaku Yamahata
2023-07-20 20:20 ` Sean Christopherson
2023-07-20 20:20 ` Sean Christopherson
2023-07-20 20:20 ` Sean Christopherson
2023-07-20 20:20 ` Sean Christopherson
2023-07-21 10:57 ` Paolo Bonzini
2023-07-21 10:57 ` Paolo Bonzini
2023-07-21 10:57 ` Paolo Bonzini
2023-07-21 10:57 ` Paolo Bonzini
2023-07-21 15:56 ` Xiaoyao Li
2023-07-21 15:56 ` Xiaoyao Li
2023-07-21 15:56 ` Xiaoyao Li
2023-07-21 15:56 ` Xiaoyao Li
2023-07-24 4:43 ` Xu Yilun
2023-07-24 4:43 ` Xu Yilun
2023-07-24 4:43 ` Xu Yilun
2023-07-26 15:59 ` Sean Christopherson
2023-07-26 15:59 ` Sean Christopherson
2023-07-26 15:59 ` Sean Christopherson
2023-07-27 3:24 ` Xu Yilun
2023-07-27 3:24 ` Xu Yilun
2023-07-27 3:24 ` Xu Yilun
2023-07-27 3:24 ` Xu Yilun
2023-08-02 20:31 ` Isaku Yamahata
2023-08-02 20:31 ` Isaku Yamahata
2023-08-02 20:31 ` Isaku Yamahata
2023-08-02 20:31 ` Isaku Yamahata
2023-08-14 0:44 ` Binbin Wu
2023-08-14 0:44 ` Binbin Wu
2023-08-14 0:44 ` Binbin Wu
2023-08-14 0:44 ` Binbin Wu
2023-08-14 21:54 ` Sean Christopherson
2023-08-14 21:54 ` Sean Christopherson
2023-08-14 21:54 ` Sean Christopherson
2023-08-14 21:54 ` Sean Christopherson
2023-07-18 23:44 ` [RFC PATCH v11 09/29] KVM: x86: Disallow hugepages when memory attributes are mixed Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-21 11:59 ` Paolo Bonzini
2023-07-21 11:59 ` Paolo Bonzini
2023-07-21 11:59 ` Paolo Bonzini
2023-07-21 11:59 ` Paolo Bonzini
2023-07-21 17:41 ` Sean Christopherson
2023-07-21 17:41 ` Sean Christopherson
2023-07-21 17:41 ` Sean Christopherson
2023-07-21 17:41 ` Sean Christopherson
2023-07-18 23:44 ` [RFC PATCH v11 10/29] mm: Add AS_UNMOVABLE to mark mapping as completely unmovable Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-25 10:24 ` Kirill A . Shutemov
2023-07-25 10:24 ` Kirill A . Shutemov
2023-07-25 10:24 ` Kirill A . Shutemov
2023-07-25 12:51 ` Matthew Wilcox
2023-07-25 12:51 ` Matthew Wilcox
2023-07-25 12:51 ` Matthew Wilcox
2023-07-26 11:36 ` Kirill A . Shutemov
2023-07-26 11:36 ` Kirill A . Shutemov
2023-07-26 11:36 ` Kirill A . Shutemov
2023-07-28 16:02 ` Vlastimil Babka
2023-07-28 16:02 ` Vlastimil Babka
2023-07-28 16:02 ` Vlastimil Babka
2023-07-28 16:02 ` Vlastimil Babka
2023-07-28 16:13 ` Paolo Bonzini
2023-07-28 16:13 ` Paolo Bonzini
2023-07-28 16:13 ` Paolo Bonzini
2023-07-28 16:13 ` Paolo Bonzini
2023-09-01 8:23 ` Vlastimil Babka
2023-09-01 8:23 ` Vlastimil Babka
2023-09-01 8:23 ` Vlastimil Babka
2023-09-01 8:23 ` Vlastimil Babka
2023-07-18 23:44 ` [RFC PATCH v11 11/29] security: Export security_inode_init_security_anon() for use by KVM Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-19 2:14 ` Paul Moore
2023-07-19 2:14 ` Paul Moore
2023-07-19 2:14 ` Paul Moore
2023-07-19 2:14 ` Paul Moore
2023-07-31 10:46 ` Vlastimil Babka
2023-07-31 10:46 ` Vlastimil Babka
2023-07-31 10:46 ` Vlastimil Babka
2023-07-31 10:46 ` Vlastimil Babka
2023-07-18 23:44 ` [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-19 17:21 ` Vishal Annapurve
2023-07-19 17:21 ` Vishal Annapurve
2023-07-19 17:21 ` Vishal Annapurve
2023-07-19 17:21 ` Vishal Annapurve
2023-07-19 17:47 ` Sean Christopherson
2023-07-19 17:47 ` Sean Christopherson
2023-07-19 17:47 ` Sean Christopherson
2023-07-19 17:47 ` Sean Christopherson
2023-07-20 14:45 ` Xiaoyao Li
2023-07-20 14:45 ` Xiaoyao Li
2023-07-20 14:45 ` Xiaoyao Li
2023-07-20 14:45 ` Xiaoyao Li
2023-07-20 15:14 ` Sean Christopherson
2023-07-20 15:14 ` Sean Christopherson
2023-07-20 15:14 ` Sean Christopherson
2023-07-20 15:14 ` Sean Christopherson
2023-07-20 21:28 ` Isaku Yamahata
2023-07-20 21:28 ` Isaku Yamahata
2023-07-20 21:28 ` Isaku Yamahata
2023-07-20 21:28 ` Isaku Yamahata
2023-07-21 6:13 ` Yuan Yao
2023-07-21 6:13 ` Yuan Yao
2023-07-21 6:13 ` Yuan Yao
2023-07-21 6:13 ` Yuan Yao
2023-07-21 22:27 ` Isaku Yamahata
2023-07-21 22:27 ` Isaku Yamahata
2023-07-21 22:27 ` Isaku Yamahata
2023-07-21 22:27 ` Isaku Yamahata
2023-07-21 22:33 ` Sean Christopherson
2023-07-21 22:33 ` Sean Christopherson
2023-07-21 22:33 ` Sean Christopherson
2023-07-21 22:33 ` Sean Christopherson
2023-07-21 15:05 ` Xiaoyao Li
2023-07-21 15:05 ` Xiaoyao Li
2023-07-21 15:05 ` Xiaoyao Li
2023-07-21 15:05 ` Xiaoyao Li
2023-07-21 15:42 ` Xiaoyao Li
2023-07-21 15:42 ` Xiaoyao Li
2023-07-21 15:42 ` Xiaoyao Li
2023-07-21 15:42 ` Xiaoyao Li
2023-07-21 17:42 ` Sean Christopherson
2023-07-21 17:42 ` Sean Christopherson
2023-07-21 17:42 ` Sean Christopherson
2023-07-21 17:42 ` Sean Christopherson
2023-07-21 17:17 ` Paolo Bonzini
2023-07-21 17:17 ` Paolo Bonzini
2023-07-21 17:17 ` Paolo Bonzini
2023-07-21 17:17 ` Paolo Bonzini
2023-07-21 17:50 ` Sean Christopherson
2023-07-21 17:50 ` Sean Christopherson
2023-07-21 17:50 ` Sean Christopherson
2023-07-21 17:50 ` Sean Christopherson
2023-07-25 15:09 ` Wang, Wei W
2023-07-25 15:09 ` Wang, Wei W
2023-07-25 15:09 ` Wang, Wei W
2023-07-25 16:03 ` Sean Christopherson
2023-07-25 16:03 ` Sean Christopherson
2023-07-25 16:03 ` Sean Christopherson
2023-07-26 1:51 ` Wang, Wei W
2023-07-26 1:51 ` Wang, Wei W
2023-07-26 1:51 ` Wang, Wei W
2023-07-31 16:23 ` Fuad Tabba
2023-07-31 16:23 ` Fuad Tabba
2023-07-31 16:23 ` Fuad Tabba
2023-07-31 16:23 ` Fuad Tabba
2023-07-26 17:18 ` Elliot Berman
2023-07-26 17:18 ` Elliot Berman
2023-07-26 17:18 ` Elliot Berman
2023-07-26 19:28 ` Sean Christopherson
2023-07-26 19:28 ` Sean Christopherson
2023-07-26 19:28 ` Sean Christopherson
2023-07-27 10:39 ` Fuad Tabba
2023-07-27 10:39 ` Fuad Tabba
2023-07-27 10:39 ` Fuad Tabba
2023-07-27 10:39 ` Fuad Tabba
2023-07-27 17:13 ` Sean Christopherson
2023-07-27 17:13 ` Sean Christopherson
2023-07-27 17:13 ` Sean Christopherson
2023-07-27 17:13 ` Sean Christopherson
2023-07-31 13:46 ` Fuad Tabba
2023-07-31 13:46 ` Fuad Tabba
2023-07-31 13:46 ` Fuad Tabba
2023-07-31 13:46 ` Fuad Tabba
2023-08-03 19:15 ` Ryan Afranji
2023-08-03 19:15 ` Ryan Afranji
2023-08-03 19:15 ` Ryan Afranji
2023-08-03 19:15 ` Ryan Afranji
2023-08-07 23:06 ` Ackerley Tng
2023-08-07 23:06 ` Ackerley Tng
2023-08-07 23:06 ` Ackerley Tng
2023-08-07 23:06 ` Ackerley Tng
2023-08-08 21:13 ` Sean Christopherson
2023-08-08 21:13 ` Sean Christopherson
2023-08-08 21:13 ` Sean Christopherson
2023-08-08 21:13 ` Sean Christopherson
2023-08-10 23:57 ` Vishal Annapurve
2023-08-10 23:57 ` Vishal Annapurve
2023-08-10 23:57 ` Vishal Annapurve
2023-08-10 23:57 ` Vishal Annapurve
2023-08-11 17:44 ` Sean Christopherson
2023-08-11 17:44 ` Sean Christopherson
2023-08-11 17:44 ` Sean Christopherson
2023-08-11 17:44 ` Sean Christopherson
2023-08-15 18:43 ` Ackerley Tng
2023-08-15 18:43 ` Ackerley Tng
2023-08-15 18:43 ` Ackerley Tng
2023-08-15 18:43 ` Ackerley Tng
2023-08-15 20:03 ` Sean Christopherson
2023-08-15 20:03 ` Sean Christopherson
2023-08-15 20:03 ` Sean Christopherson
2023-08-15 20:03 ` Sean Christopherson
2023-08-21 17:30 ` Ackerley Tng
2023-08-21 17:30 ` Ackerley Tng
2023-08-21 17:30 ` Ackerley Tng
2023-08-21 17:30 ` Ackerley Tng
2023-08-21 19:33 ` Sean Christopherson
2023-08-21 19:33 ` Sean Christopherson
2023-08-21 19:33 ` Sean Christopherson
2023-08-21 19:33 ` Sean Christopherson
2023-08-28 22:56 ` Ackerley Tng
2023-08-28 22:56 ` Ackerley Tng
2023-08-28 22:56 ` Ackerley Tng
2023-08-28 22:56 ` Ackerley Tng
2023-08-29 2:53 ` Elliot Berman
2023-08-29 2:53 ` Elliot Berman
2023-08-29 2:53 ` Elliot Berman
2023-08-29 2:53 ` Elliot Berman
2023-09-14 19:12 ` Sean Christopherson [this message]
2023-09-14 19:12 ` Sean Christopherson
2023-09-14 19:12 ` Sean Christopherson
2023-09-14 19:12 ` Sean Christopherson
2023-09-14 18:15 ` Sean Christopherson
2023-09-14 18:15 ` Sean Christopherson
2023-09-14 18:15 ` Sean Christopherson
2023-09-14 18:15 ` Sean Christopherson
2023-09-14 23:19 ` Ackerley Tng
2023-09-14 23:19 ` Ackerley Tng
2023-09-14 23:19 ` Ackerley Tng
2023-09-14 23:19 ` Ackerley Tng
2023-09-15 0:33 ` Sean Christopherson
2023-09-15 0:33 ` Sean Christopherson
2023-09-15 0:33 ` Sean Christopherson
2023-09-15 0:33 ` Sean Christopherson
2023-08-30 15:12 ` Binbin Wu
2023-08-30 15:12 ` Binbin Wu
2023-08-30 15:12 ` Binbin Wu
2023-08-30 15:12 ` Binbin Wu
2023-08-30 16:44 ` Ackerley Tng
2023-08-30 16:44 ` Ackerley Tng
2023-08-30 16:44 ` Ackerley Tng
2023-08-30 16:44 ` Ackerley Tng
2023-09-01 3:45 ` Binbin Wu
2023-09-01 3:45 ` Binbin Wu
2023-09-01 3:45 ` Binbin Wu
2023-09-01 3:45 ` Binbin Wu
2023-09-01 16:46 ` Ackerley Tng
2023-09-01 16:46 ` Ackerley Tng
2023-09-01 16:46 ` Ackerley Tng
2023-09-01 16:46 ` Ackerley Tng
2023-07-18 23:44 ` [RFC PATCH v11 13/29] KVM: Add transparent hugepage support for dedicated guest memory Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-21 15:07 ` Paolo Bonzini
2023-07-21 15:07 ` Paolo Bonzini
2023-07-21 15:07 ` Paolo Bonzini
2023-07-21 15:07 ` Paolo Bonzini
2023-07-21 17:13 ` Sean Christopherson
2023-07-21 17:13 ` Sean Christopherson
2023-07-21 17:13 ` Sean Christopherson
2023-07-21 17:13 ` Sean Christopherson
2023-09-06 22:10 ` Paolo Bonzini
2023-09-06 22:10 ` Paolo Bonzini
2023-09-06 22:10 ` Paolo Bonzini
2023-09-06 22:10 ` Paolo Bonzini
2023-07-18 23:44 ` [RFC PATCH v11 14/29] KVM: x86/mmu: Handle page fault for private memory Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-21 15:09 ` Paolo Bonzini
2023-07-21 15:09 ` Paolo Bonzini
2023-07-21 15:09 ` Paolo Bonzini
2023-07-21 15:09 ` Paolo Bonzini
2023-07-18 23:44 ` [RFC PATCH v11 15/29] KVM: Drop superfluous __KVM_VCPU_MULTIPLE_ADDRESS_SPACE macro Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-21 15:07 ` Paolo Bonzini
2023-07-21 15:07 ` Paolo Bonzini
2023-07-21 15:07 ` Paolo Bonzini
2023-07-21 15:07 ` Paolo Bonzini
2023-07-18 23:44 ` [RFC PATCH v11 16/29] KVM: Allow arch code to track number of memslot address spaces per VM Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-18 23:44 ` Sean Christopherson
2023-07-21 15:12 ` Paolo Bonzini
2023-07-21 15:12 ` Paolo Bonzini
2023-07-21 15:12 ` Paolo Bonzini
2023-07-21 15:12 ` Paolo Bonzini
2023-07-18 23:45 ` [RFC PATCH v11 17/29] KVM: x86: Add support for "protected VMs" that can utilize private memory Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 18/29] KVM: selftests: Drop unused kvm_userspace_memory_region_find() helper Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-21 15:14 ` Paolo Bonzini
2023-07-21 15:14 ` Paolo Bonzini
2023-07-21 15:14 ` Paolo Bonzini
2023-07-21 15:14 ` Paolo Bonzini
2023-07-18 23:45 ` [RFC PATCH v11 19/29] KVM: selftests: Convert lib's mem regions to KVM_SET_USER_MEMORY_REGION2 Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 20/29] KVM: selftests: Add support for creating private memslots Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 21/29] KVM: selftests: Add helpers to convert guest memory b/w private and shared Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 22/29] KVM: selftests: Add helpers to do KVM_HC_MAP_GPA_RANGE hypercalls (x86) Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 23/29] KVM: selftests: Introduce VM "shape" to allow tests to specify the VM type Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 24/29] KVM: selftests: Add GUEST_SYNC[1-6] macros for synchronizing more data Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 25/29] KVM: selftests: Add x86-only selftest for private memory conversions Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 26/29] KVM: selftests: Add KVM_SET_USER_MEMORY_REGION2 helper Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` [RFC PATCH v11 27/29] KVM: selftests: Expand set_memory_region_test to validate guest_memfd() Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-08-07 23:17 ` Ackerley Tng
2023-08-07 23:17 ` Ackerley Tng
2023-08-07 23:17 ` Ackerley Tng
2023-08-07 23:17 ` Ackerley Tng
2023-07-18 23:45 ` [RFC PATCH v11 28/29] KVM: selftests: Add basic selftest for guest_memfd() Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-08-07 23:20 ` Ackerley Tng
2023-08-07 23:20 ` Ackerley Tng
2023-08-07 23:20 ` Ackerley Tng
2023-08-07 23:20 ` Ackerley Tng
2023-08-18 23:03 ` Sean Christopherson
2023-08-18 23:03 ` Sean Christopherson
2023-08-18 23:03 ` Sean Christopherson
2023-08-18 23:03 ` Sean Christopherson
2023-08-07 23:25 ` Ackerley Tng
2023-08-07 23:25 ` Ackerley Tng
2023-08-07 23:25 ` Ackerley Tng
2023-08-07 23:25 ` Ackerley Tng
2023-08-18 23:01 ` Sean Christopherson
2023-08-18 23:01 ` Sean Christopherson
2023-08-18 23:01 ` Sean Christopherson
2023-08-18 23:01 ` Sean Christopherson
2023-08-21 19:49 ` Ackerley Tng
2023-08-21 19:49 ` Ackerley Tng
2023-08-21 19:49 ` Ackerley Tng
2023-08-21 19:49 ` Ackerley Tng
2023-07-18 23:45 ` [RFC PATCH v11 29/29] KVM: selftests: Test KVM exit behavior for private memory/access Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-18 23:45 ` Sean Christopherson
2023-07-24 6:38 ` [RFC PATCH v11 00/29] KVM: guest_memfd() and per-page attributes Nikunj A. Dadhania
2023-07-24 6:38 ` Nikunj A. Dadhania
2023-07-24 6:38 ` Nikunj A. Dadhania
2023-07-24 17:00 ` Sean Christopherson
2023-07-24 17:00 ` Sean Christopherson
2023-07-24 17:00 ` Sean Christopherson
2023-07-26 11:20 ` Nikunj A. Dadhania
2023-07-26 11:20 ` Nikunj A. Dadhania
2023-07-26 11:20 ` Nikunj A. Dadhania
2023-07-26 14:24 ` Sean Christopherson
2023-07-26 14:24 ` Sean Christopherson
2023-07-26 14:24 ` Sean Christopherson
2023-07-27 6:42 ` Nikunj A. Dadhania
2023-07-27 6:42 ` Nikunj A. Dadhania
2023-07-27 6:42 ` Nikunj A. Dadhania
2023-07-27 6:42 ` Nikunj A. Dadhania
2023-08-03 11:03 ` Vlastimil Babka
2023-08-03 11:03 ` Vlastimil Babka
2023-08-03 11:03 ` Vlastimil Babka
2023-08-03 11:03 ` Vlastimil Babka
2023-07-24 20:16 ` Sean Christopherson
2023-08-25 17:47 ` Sean Christopherson
2023-08-29 9:12 ` Chao Peng
2023-08-31 18:29 ` Sean Christopherson
2023-09-01 1:17 ` Chao Peng
2023-09-01 8:26 ` Vlastimil Babka
2023-09-01 9:10 ` Paolo Bonzini
2023-08-30 0:00 ` Isaku Yamahata
2023-09-09 0:16 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZQNbDt6vqwC4gZmi@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=chao.p.peng@linux.intel.com \
--cc=chenhuacai@kernel.org \
--cc=david@redhat.com \
--cc=isaku.yamahata@gmail.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=liam.merwick@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mail@maciej.szmigiero.name \
--cc=maz@kernel.org \
--cc=michael.roth@amd.com \
--cc=mpe@ellerman.id.au \
--cc=oliver.upton@linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=paul@paul-moore.com \
--cc=pbonzini@redhat.com \
--cc=qperret@google.com \
--cc=quic_eberman@quicinc.com \
--cc=serge@hallyn.com \
--cc=tabba@google.com \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--cc=wei.w.wang@intel.com \
--cc=willy@infradead.org \
--cc=yu.c.zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.