From: Chao Peng <chao.p.peng@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, qemu-devel@nongnu.org,
Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
Hugh Dickins <hughd@google.com>, Jeff Layton <jlayton@kernel.org>,
"J . Bruce Fields" <bfields@fieldses.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>,
Steven Price <steven.price@arm.com>,
"Maciej S . Szmigiero" <mail@maciej.szmigiero.name>,
Vlastimil Babka <vbabka@suse.cz>,
Vishal Annapurve <vannapurve@google.com>,
Yu Zhang <yu.c.zhang@linux.intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com,
ak@linux.intel.com, david@redhat.com
Subject: Re: [PATCH v5 12/13] KVM: Expose KVM_MEM_PRIVATE
Date: Tue, 12 Apr 2022 20:56:18 +0800 [thread overview]
Message-ID: <20220412125618.GC8013@chaop.bj.intel.com> (raw)
In-Reply-To: <YkNaPLVLk/pO0zjr@google.com>
On Tue, Mar 29, 2022 at 07:13:00PM +0000, Sean Christopherson wrote:
> On Thu, Mar 10, 2022, Chao Peng wrote:
> > KVM_MEM_PRIVATE is not exposed by default but architecture code can turn
> > on it by implementing kvm_arch_private_memory_supported().
> >
> > Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> > Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> > ---
> > include/linux/kvm_host.h | 1 +
> > virt/kvm/kvm_main.c | 24 +++++++++++++++++++-----
> > 2 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 186b9b981a65..0150e952a131 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -1432,6 +1432,7 @@ bool kvm_arch_dy_has_pending_interrupt(struct kvm_vcpu *vcpu);
> > int kvm_arch_post_init_vm(struct kvm *kvm);
> > void kvm_arch_pre_destroy_vm(struct kvm *kvm);
> > int kvm_arch_create_vm_debugfs(struct kvm *kvm);
> > +bool kvm_arch_private_memory_supported(struct kvm *kvm);
> >
> > #ifndef __KVM_HAVE_ARCH_VM_ALLOC
> > /*
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 52319f49d58a..df5311755a40 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -1485,10 +1485,19 @@ static void kvm_replace_memslot(struct kvm *kvm,
> > }
> > }
> >
> > -static int check_memory_region_flags(const struct kvm_userspace_memory_region *mem)
> > +bool __weak kvm_arch_private_memory_supported(struct kvm *kvm)
> > +{
> > + return false;
> > +}
> > +
> > +static int check_memory_region_flags(struct kvm *kvm,
> > + const struct kvm_userspace_memory_region *mem)
> > {
> > u32 valid_flags = KVM_MEM_LOG_DIRTY_PAGES;
> >
> > + if (kvm_arch_private_memory_supported(kvm))
> > + valid_flags |= KVM_MEM_PRIVATE;
> > +
> > #ifdef __KVM_HAVE_READONLY_MEM
> > valid_flags |= KVM_MEM_READONLY;
> > #endif
> > @@ -1900,7 +1909,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
> > int as_id, id;
> > int r;
> >
> > - r = check_memory_region_flags(mem);
> > + r = check_memory_region_flags(kvm, mem);
> > if (r)
> > return r;
> >
> > @@ -1913,10 +1922,12 @@ int __kvm_set_memory_region(struct kvm *kvm,
> > return -EINVAL;
> > if (mem->guest_phys_addr & (PAGE_SIZE - 1))
> > return -EINVAL;
> > - /* We can read the guest memory with __xxx_user() later on. */
> > if ((mem->userspace_addr & (PAGE_SIZE - 1)) ||
> > - (mem->userspace_addr != untagged_addr(mem->userspace_addr)) ||
> > - !access_ok((void __user *)(unsigned long)mem->userspace_addr,
> > + (mem->userspace_addr != untagged_addr(mem->userspace_addr)))
> > + return -EINVAL;
> > + /* We can read the guest memory with __xxx_user() later on. */
> > + if (!(mem->flags & KVM_MEM_PRIVATE) &&
> > + !access_ok((void __user *)(unsigned long)mem->userspace_addr,
>
> This should sanity check private_offset for private memslots. At a bare minimum,
> wrapping should be disallowed.
Will add this.
>
> > mem->memory_size))
> > return -EINVAL;
> > if (as_id >= KVM_ADDRESS_SPACE_NUM || id >= KVM_MEM_SLOTS_NUM)
> > @@ -1957,6 +1968,9 @@ int __kvm_set_memory_region(struct kvm *kvm,
> > if ((kvm->nr_memslot_pages + npages) < kvm->nr_memslot_pages)
> > return -EINVAL;
> > } else { /* Modify an existing slot. */
> > + /* Private memslots are immutable, they can only be deleted. */
> > + if (mem->flags & KVM_MEM_PRIVATE)
> > + return -EINVAL;
>
> These sanity checks belong in "KVM: Register private memslot to memory backing store",
> e.g. that patch is "broken" without the immutability restriction. It's somewhat moot
> because the code is unreachable, but it makes reviewing confusing/difficult.
>
> But rather than move the sanity checks back, I think I'd prefer to pull all of patch 10
> here. I think it also makes sense to drop "KVM: Use memfile_pfn_ops to obtain pfn for
> private pages" and add the pointer in "struct kvm_memory_slot" in patch "KVM: Extend the
> memslot to support fd-based private memory", with the use of the ops folded into
> "KVM: Handle page fault for private memory". Adding code to KVM and KVM-x86 in a single
> patch is ok, and overall makes things easier to review because the new helpers have a
> user right away, especially since there will be #ifdeffery.
>
> I.e. end up with something like:
>
> mm: Introduce memfile_notifier
> mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK
> KVM: Extend the memslot to support fd-based private memory
> KVM: Use kvm_userspace_memory_region_ext
> KVM: Add KVM_EXIT_MEMORY_ERROR exit
> KVM: Handle page fault for private memory
> KVM: Register private memslot to memory backing store
> KVM: Zap existing KVM mappings when pages changed in the private fd
> KVM: Enable and expose KVM_MEM_PRIVATE
Thanks for the suggestion. That makes sense.
Chao
>
> > if ((mem->userspace_addr != old->userspace_addr) ||
> > (npages != old->npages) ||
> > ((mem->flags ^ old->flags) & KVM_MEM_READONLY))
> > --
> > 2.17.1
> >
WARNING: multiple messages have this Message-ID (diff)
From: Chao Peng <chao.p.peng@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Wanpeng Li <wanpengli@tencent.com>,
jun.nakajima@intel.com, kvm@vger.kernel.org, david@redhat.com,
qemu-devel@nongnu.org, "J . Bruce Fields" <bfields@fieldses.org>,
linux-mm@kvack.org, "H . Peter Anvin" <hpa@zytor.com>,
ak@linux.intel.com, Jonathan Corbet <corbet@lwn.net>,
Joerg Roedel <joro@8bytes.org>,
x86@kernel.org, Hugh Dickins <hughd@google.com>,
Steven Price <steven.price@arm.com>,
Ingo Molnar <mingo@redhat.com>,
"Maciej S . Szmigiero" <mail@maciej.szmigiero.name>,
Borislav Petkov <bp@alien8.de>,
luto@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Vlastimil Babka <vbabka@suse.cz>,
Jim Mattson <jmattson@google.com>,
dave.hansen@intel.com, linux-api@vger.kernel.org,
Jeff Layton <jlayton@kernel.org>,
linux-kernel@vger.kernel.org,
Yu Zhang <yu.c.zhang@linux.intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
linux-fsdevel@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vishal Annapurve <vannapurve@google.com>,
Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v5 12/13] KVM: Expose KVM_MEM_PRIVATE
Date: Tue, 12 Apr 2022 20:56:18 +0800 [thread overview]
Message-ID: <20220412125618.GC8013@chaop.bj.intel.com> (raw)
In-Reply-To: <YkNaPLVLk/pO0zjr@google.com>
On Tue, Mar 29, 2022 at 07:13:00PM +0000, Sean Christopherson wrote:
> On Thu, Mar 10, 2022, Chao Peng wrote:
> > KVM_MEM_PRIVATE is not exposed by default but architecture code can turn
> > on it by implementing kvm_arch_private_memory_supported().
> >
> > Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
> > Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> > ---
> > include/linux/kvm_host.h | 1 +
> > virt/kvm/kvm_main.c | 24 +++++++++++++++++++-----
> > 2 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index 186b9b981a65..0150e952a131 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -1432,6 +1432,7 @@ bool kvm_arch_dy_has_pending_interrupt(struct kvm_vcpu *vcpu);
> > int kvm_arch_post_init_vm(struct kvm *kvm);
> > void kvm_arch_pre_destroy_vm(struct kvm *kvm);
> > int kvm_arch_create_vm_debugfs(struct kvm *kvm);
> > +bool kvm_arch_private_memory_supported(struct kvm *kvm);
> >
> > #ifndef __KVM_HAVE_ARCH_VM_ALLOC
> > /*
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 52319f49d58a..df5311755a40 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -1485,10 +1485,19 @@ static void kvm_replace_memslot(struct kvm *kvm,
> > }
> > }
> >
> > -static int check_memory_region_flags(const struct kvm_userspace_memory_region *mem)
> > +bool __weak kvm_arch_private_memory_supported(struct kvm *kvm)
> > +{
> > + return false;
> > +}
> > +
> > +static int check_memory_region_flags(struct kvm *kvm,
> > + const struct kvm_userspace_memory_region *mem)
> > {
> > u32 valid_flags = KVM_MEM_LOG_DIRTY_PAGES;
> >
> > + if (kvm_arch_private_memory_supported(kvm))
> > + valid_flags |= KVM_MEM_PRIVATE;
> > +
> > #ifdef __KVM_HAVE_READONLY_MEM
> > valid_flags |= KVM_MEM_READONLY;
> > #endif
> > @@ -1900,7 +1909,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
> > int as_id, id;
> > int r;
> >
> > - r = check_memory_region_flags(mem);
> > + r = check_memory_region_flags(kvm, mem);
> > if (r)
> > return r;
> >
> > @@ -1913,10 +1922,12 @@ int __kvm_set_memory_region(struct kvm *kvm,
> > return -EINVAL;
> > if (mem->guest_phys_addr & (PAGE_SIZE - 1))
> > return -EINVAL;
> > - /* We can read the guest memory with __xxx_user() later on. */
> > if ((mem->userspace_addr & (PAGE_SIZE - 1)) ||
> > - (mem->userspace_addr != untagged_addr(mem->userspace_addr)) ||
> > - !access_ok((void __user *)(unsigned long)mem->userspace_addr,
> > + (mem->userspace_addr != untagged_addr(mem->userspace_addr)))
> > + return -EINVAL;
> > + /* We can read the guest memory with __xxx_user() later on. */
> > + if (!(mem->flags & KVM_MEM_PRIVATE) &&
> > + !access_ok((void __user *)(unsigned long)mem->userspace_addr,
>
> This should sanity check private_offset for private memslots. At a bare minimum,
> wrapping should be disallowed.
Will add this.
>
> > mem->memory_size))
> > return -EINVAL;
> > if (as_id >= KVM_ADDRESS_SPACE_NUM || id >= KVM_MEM_SLOTS_NUM)
> > @@ -1957,6 +1968,9 @@ int __kvm_set_memory_region(struct kvm *kvm,
> > if ((kvm->nr_memslot_pages + npages) < kvm->nr_memslot_pages)
> > return -EINVAL;
> > } else { /* Modify an existing slot. */
> > + /* Private memslots are immutable, they can only be deleted. */
> > + if (mem->flags & KVM_MEM_PRIVATE)
> > + return -EINVAL;
>
> These sanity checks belong in "KVM: Register private memslot to memory backing store",
> e.g. that patch is "broken" without the immutability restriction. It's somewhat moot
> because the code is unreachable, but it makes reviewing confusing/difficult.
>
> But rather than move the sanity checks back, I think I'd prefer to pull all of patch 10
> here. I think it also makes sense to drop "KVM: Use memfile_pfn_ops to obtain pfn for
> private pages" and add the pointer in "struct kvm_memory_slot" in patch "KVM: Extend the
> memslot to support fd-based private memory", with the use of the ops folded into
> "KVM: Handle page fault for private memory". Adding code to KVM and KVM-x86 in a single
> patch is ok, and overall makes things easier to review because the new helpers have a
> user right away, especially since there will be #ifdeffery.
>
> I.e. end up with something like:
>
> mm: Introduce memfile_notifier
> mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK
> KVM: Extend the memslot to support fd-based private memory
> KVM: Use kvm_userspace_memory_region_ext
> KVM: Add KVM_EXIT_MEMORY_ERROR exit
> KVM: Handle page fault for private memory
> KVM: Register private memslot to memory backing store
> KVM: Zap existing KVM mappings when pages changed in the private fd
> KVM: Enable and expose KVM_MEM_PRIVATE
Thanks for the suggestion. That makes sense.
Chao
>
> > if ((mem->userspace_addr != old->userspace_addr) ||
> > (npages != old->npages) ||
> > ((mem->flags ^ old->flags) & KVM_MEM_READONLY))
> > --
> > 2.17.1
> >
next prev parent reply other threads:[~2022-04-12 13:12 UTC|newest]
Thread overview: 183+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 14:08 [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory Chao Peng
2022-03-10 14:08 ` Chao Peng
2022-03-10 14:08 ` [PATCH v5 01/13] mm/memfd: Introduce MFD_INACCESSIBLE flag Chao Peng
2022-03-10 14:08 ` Chao Peng
2022-04-11 15:10 ` Kirill A. Shutemov
2022-04-11 15:10 ` Kirill A. Shutemov
2022-04-12 13:11 ` Chao Peng
2022-04-12 13:11 ` Chao Peng
2022-04-23 5:43 ` Vishal Annapurve
2022-04-24 8:15 ` Chao Peng
2022-04-24 8:15 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 02/13] mm: Introduce memfile_notifier Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-29 18:45 ` Sean Christopherson
2022-04-08 12:54 ` Chao Peng
2022-04-08 12:54 ` Chao Peng
2022-04-12 14:36 ` Hillf Danton
2022-04-13 6:47 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 03/13] mm/shmem: Support memfile_notifier Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-10 23:08 ` Dave Chinner
2022-03-10 23:08 ` Dave Chinner
2022-03-11 8:42 ` Chao Peng
2022-03-11 8:42 ` Chao Peng
2022-04-11 15:26 ` Kirill A. Shutemov
2022-04-11 15:26 ` Kirill A. Shutemov
2022-04-12 13:12 ` Chao Peng
2022-04-12 13:12 ` Chao Peng
2022-04-19 22:40 ` Vishal Annapurve
2022-04-20 3:24 ` Chao Peng
2022-04-20 3:24 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 04/13] mm/shmem: Restrict MFD_INACCESSIBLE memory against RLIMIT_MEMLOCK Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-04-07 16:05 ` Sean Christopherson
2022-04-07 17:09 ` Andy Lutomirski
2022-04-07 17:09 ` Andy Lutomirski
2022-04-08 17:56 ` Sean Christopherson
2022-04-08 18:54 ` David Hildenbrand
2022-04-08 18:54 ` David Hildenbrand
2022-04-12 14:36 ` Jason Gunthorpe
2022-04-12 14:36 ` Jason Gunthorpe
2022-04-12 21:27 ` Andy Lutomirski
2022-04-12 21:27 ` Andy Lutomirski
2022-04-13 16:30 ` David Hildenbrand
2022-04-13 16:30 ` David Hildenbrand
2022-04-13 16:24 ` David Hildenbrand
2022-04-13 16:24 ` David Hildenbrand
2022-04-13 17:52 ` Jason Gunthorpe
2022-04-13 17:52 ` Jason Gunthorpe
2022-04-25 14:07 ` David Hildenbrand
2022-04-25 14:07 ` David Hildenbrand
2022-04-08 13:02 ` Chao Peng
2022-04-08 13:02 ` Chao Peng
2022-04-11 15:34 ` Kirill A. Shutemov
2022-04-11 15:34 ` Kirill A. Shutemov
2022-04-12 5:14 ` Hugh Dickins
2022-04-11 15:32 ` Kirill A. Shutemov
2022-04-11 15:32 ` Kirill A. Shutemov
2022-04-12 13:39 ` Chao Peng
2022-04-12 13:39 ` Chao Peng
2022-04-12 19:28 ` Kirill A. Shutemov
2022-04-12 19:28 ` Kirill A. Shutemov
2022-04-13 9:15 ` Chao Peng
2022-04-13 9:15 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 05/13] KVM: Extend the memslot to support fd-based private memory Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-28 21:27 ` Sean Christopherson
2022-04-08 13:21 ` Chao Peng
2022-04-08 13:21 ` Chao Peng
2022-03-28 21:56 ` Sean Christopherson
2022-04-08 13:46 ` Chao Peng
2022-04-08 13:46 ` Chao Peng
2022-04-08 17:45 ` Sean Christopherson
2022-03-10 14:09 ` [PATCH v5 06/13] KVM: Use kvm_userspace_memory_region_ext Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-28 22:26 ` Sean Christopherson
2022-04-08 13:58 ` Chao Peng
2022-04-08 13:58 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 07/13] KVM: Add KVM_EXIT_MEMORY_ERROR exit Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-28 22:33 ` Sean Christopherson
2022-04-08 13:59 ` Chao Peng
2022-04-08 13:59 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 08/13] KVM: Use memfile_pfn_ops to obtain pfn for private pages Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-28 23:56 ` Sean Christopherson
2022-04-08 14:07 ` Chao Peng
2022-04-08 14:07 ` Chao Peng
2022-04-28 12:37 ` Chao Peng
2022-04-28 12:37 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 09/13] KVM: Handle page fault for private memory Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-29 1:07 ` Sean Christopherson
2022-04-12 12:10 ` Chao Peng
2022-04-12 12:10 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 10/13] KVM: Register private memslot to memory backing store Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-29 19:01 ` Sean Christopherson
2022-04-12 12:40 ` Chao Peng
2022-04-12 12:40 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 11/13] KVM: Zap existing KVM mappings when pages changed in the private fd Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-29 19:23 ` Sean Christopherson
2022-04-12 12:43 ` Chao Peng
2022-04-12 12:43 ` Chao Peng
2022-04-05 23:45 ` Michael Roth
2022-04-08 3:06 ` Sean Christopherson
2022-04-19 22:43 ` Vishal Annapurve
2022-04-20 3:17 ` Chao Peng
2022-04-20 3:17 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 12/13] KVM: Expose KVM_MEM_PRIVATE Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-29 19:13 ` Sean Christopherson
2022-04-12 12:56 ` Chao Peng [this message]
2022-04-12 12:56 ` Chao Peng
2022-03-10 14:09 ` [PATCH v5 13/13] memfd_create.2: Describe MFD_INACCESSIBLE flag Chao Peng
2022-03-10 14:09 ` Chao Peng
2022-03-24 15:51 ` [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory Quentin Perret
2022-03-28 17:13 ` Sean Christopherson
2022-03-28 18:00 ` Quentin Perret
2022-03-28 18:58 ` Sean Christopherson
2022-03-29 17:01 ` Quentin Perret
2022-03-30 8:58 ` Steven Price
2022-03-30 8:58 ` Steven Price
2022-03-30 10:39 ` Quentin Perret
2022-03-30 17:58 ` Sean Christopherson
2022-03-31 16:04 ` Andy Lutomirski
2022-03-31 16:04 ` Andy Lutomirski
2022-04-01 14:59 ` Quentin Perret
2022-04-01 17:14 ` Sean Christopherson
2022-04-01 18:03 ` Quentin Perret
2022-04-01 18:24 ` Sean Christopherson
2022-04-01 19:56 ` Andy Lutomirski
2022-04-01 19:56 ` Andy Lutomirski
2022-04-04 15:01 ` Quentin Perret
2022-04-04 17:06 ` Sean Christopherson
2022-04-04 22:04 ` Andy Lutomirski
2022-04-04 22:04 ` Andy Lutomirski
2022-04-05 10:36 ` Quentin Perret
2022-04-05 17:51 ` Andy Lutomirski
2022-04-05 17:51 ` Andy Lutomirski
2022-04-05 18:30 ` Sean Christopherson
2022-04-06 18:42 ` Andy Lutomirski
2022-04-06 18:42 ` Andy Lutomirski
2022-04-06 13:05 ` Quentin Perret
2022-04-05 18:03 ` Sean Christopherson
2022-04-06 10:34 ` Quentin Perret
2022-04-22 10:56 ` Chao Peng
2022-04-22 10:56 ` Chao Peng
2022-04-22 11:06 ` Paolo Bonzini
2022-04-22 11:06 ` Paolo Bonzini
2022-04-24 8:07 ` Chao Peng
2022-04-24 8:07 ` Chao Peng
2022-04-24 16:59 ` Andy Lutomirski
2022-04-24 16:59 ` Andy Lutomirski
2022-04-25 13:40 ` Chao Peng
2022-04-25 13:40 ` Chao Peng
2022-04-25 14:52 ` Andy Lutomirski
2022-04-25 14:52 ` Andy Lutomirski
2022-04-25 20:30 ` Sean Christopherson
2022-06-10 19:18 ` Andy Lutomirski
2022-06-10 19:27 ` Sean Christopherson
2022-04-28 12:29 ` Chao Peng
2022-04-28 12:29 ` Chao Peng
2022-05-03 11:12 ` Quentin Perret
2022-05-09 22:30 ` Michael Roth
2022-05-09 23:29 ` Sean Christopherson
2022-07-21 20:05 ` Gupta, Pankaj
2022-07-21 21:19 ` Sean Christopherson
2022-07-21 21:36 ` Gupta, Pankaj
2022-07-23 3:09 ` Andy Lutomirski
2022-07-25 9:19 ` Gupta, Pankaj
2022-03-30 16:18 ` Sean Christopherson
2022-03-28 20:16 ` Andy Lutomirski
2022-03-28 20:16 ` Andy Lutomirski
2022-03-28 22:48 ` Nakajima, Jun
2022-03-28 22:48 ` Nakajima, Jun
2022-03-29 0:04 ` Sean Christopherson
2022-04-08 21:35 ` Vishal Annapurve
2022-04-12 13:00 ` Chao Peng
2022-04-12 13:00 ` Chao Peng
2022-04-12 19:58 ` Kirill A. Shutemov
2022-04-12 19:58 ` Kirill A. Shutemov
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=20220412125618.GC8013@chaop.bj.intel.com \
--to=chao.p.peng@linux.intel.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=jlayton@kernel.org \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=jun.nakajima@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=steven.price@arm.com \
--cc=tglx@linutronix.de \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.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.