From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: David Stevens <stevensd@chromium.org>
Cc: Sean Christopherson <seanjc@google.com>,
Marc Zyngier <maz@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Peter Xu <peterx@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v7 2/8] KVM: Introduce __kvm_follow_pfn function
Date: Wed, 5 Jul 2023 18:53:43 +0800 [thread overview]
Message-ID: <20230705105343.iounmlflfued7lco@linux.intel.com> (raw)
In-Reply-To: <CAD=HUj6-VbznOOtn5WJee7Of_nh33ygg7_ph2G=hgnvNk_Cbsw@mail.gmail.com>
On Wed, Jul 05, 2023 at 06:22:59PM +0900, David Stevens wrote:
> On Wed, Jul 5, 2023 at 12:10 PM Yu Zhang <yu.c.zhang@linux.intel.com> wrote:
> >
> > > @@ -2514,35 +2512,26 @@ static bool hva_to_pfn_fast(unsigned long addr, bool write_fault,
> > > * The slow path to get the pfn of the specified host virtual address,
> > > * 1 indicates success, -errno is returned if error is detected.
> > > */
> > > -static int hva_to_pfn_slow(unsigned long addr, bool *async, bool write_fault,
> > > - bool interruptible, bool *writable, kvm_pfn_t *pfn)
> > > +static int hva_to_pfn_slow(struct kvm_follow_pfn *foll, kvm_pfn_t *pfn)
> > > {
> > > - unsigned int flags = FOLL_HWPOISON;
> > > + unsigned int flags = FOLL_HWPOISON | FOLL_GET | foll->flags;
> > > struct page *page;
> > > int npages;
> > >
> > > might_sleep();
> > >
> > > - if (writable)
> > > - *writable = write_fault;
> > > -
> > > - if (write_fault)
> > > - flags |= FOLL_WRITE;
> > > - if (async)
> > > - flags |= FOLL_NOWAIT;
> > > - if (interruptible)
> > > - flags |= FOLL_INTERRUPTIBLE;
> > > -
> > > - npages = get_user_pages_unlocked(addr, 1, &page, flags);
> > > + npages = get_user_pages_unlocked(foll->hva, 1, &page, flags);
> > > if (npages != 1)
> > > return npages;
> > >
> > > + foll->writable = (foll->flags & FOLL_WRITE) && foll->allow_write_mapping;
> > > +
> > > /* map read fault as writable if possible */
> > > - if (unlikely(!write_fault) && writable) {
> > > + if (unlikely(!foll->writable) && foll->allow_write_mapping) {
> >
> > I guess !foll->writable should be !(foll->flags & FOLL_WRITE) here.
>
> The two statements are logically equivalent, although I guess using
> !(foll->flags & FOLL_WRITE) may be a little clearer, if a little more
> verbose.
Well, as the comment says, we wanna try to map the read fault as writable
whenever possible. And __gfn_to_pfn_memslot() will only set the FOLL_WRITE
for write faults. So I guess using !foll->writable will not allow this.
Did I miss anything?
> > > +kvm_pfn_t __gfn_to_pfn_memslot(const struct kvm_memory_slot *slot, gfn_t gfn,
> > > + bool atomic, bool interruptible, bool *async,
> > > + bool write_fault, bool *writable, hva_t *hva)
> > > +{
> > > + kvm_pfn_t pfn;
> > > + struct kvm_follow_pfn foll = {
> > > + .slot = slot,
> > > + .gfn = gfn,
> > > + .flags = 0,
> > > + .atomic = atomic,
> > > + .allow_write_mapping = !!writable,
> > > + };
> > > +
> > > + if (write_fault)
> > > + foll.flags |= FOLL_WRITE;
> > > + if (async)
> > > + foll.flags |= FOLL_NOWAIT;
> > > + if (interruptible)
> > > + foll.flags |= FOLL_INTERRUPTIBLE;
> > > +
> > > + pfn = __kvm_follow_pfn(&foll);
> > > + if (pfn == KVM_PFN_ERR_NEEDS_IO) {
> >
> > Could we just use KVM_PFN_ERR_FAULT and foll.flags here? I.e.,
> > if (pfn == KVM_PFN_ERR_FAULT && (foll.flags & FOLL_NOWAIT))?
> > Setting pfn to KVM_PFN_ERR_NEEDS_IO just to indicate an async fault
> > seems unnecessary.
>
> There are the cases where the fault does not fall within a vma or when
> the target vma's flags don't support the fault's access permissions.
> In those cases, continuing to try to resolve the fault won't cause
> problems per-se, but it's wasteful and a bit confusing. Having
> hva_to_pfn detect whether or not it may be possible to resolve the
> fault asynchronously and return KVM_PFN_ERR_NEEDS_IO if so seems like
> a good idea. It also matches what the existing code does.
Got it. Sounds reasonable. And thanks! :)
B.R.
Yu
WARNING: multiple messages have this Message-ID (diff)
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: David Stevens <stevensd@chromium.org>
Cc: Marc Zyngier <maz@kernel.org>,
kvm@vger.kernel.org, Sean Christopherson <seanjc@google.com>,
linux-kernel@vger.kernel.org, Peter Xu <peterx@redhat.com>,
kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 2/8] KVM: Introduce __kvm_follow_pfn function
Date: Wed, 5 Jul 2023 18:53:43 +0800 [thread overview]
Message-ID: <20230705105343.iounmlflfued7lco@linux.intel.com> (raw)
In-Reply-To: <CAD=HUj6-VbznOOtn5WJee7Of_nh33ygg7_ph2G=hgnvNk_Cbsw@mail.gmail.com>
On Wed, Jul 05, 2023 at 06:22:59PM +0900, David Stevens wrote:
> On Wed, Jul 5, 2023 at 12:10 PM Yu Zhang <yu.c.zhang@linux.intel.com> wrote:
> >
> > > @@ -2514,35 +2512,26 @@ static bool hva_to_pfn_fast(unsigned long addr, bool write_fault,
> > > * The slow path to get the pfn of the specified host virtual address,
> > > * 1 indicates success, -errno is returned if error is detected.
> > > */
> > > -static int hva_to_pfn_slow(unsigned long addr, bool *async, bool write_fault,
> > > - bool interruptible, bool *writable, kvm_pfn_t *pfn)
> > > +static int hva_to_pfn_slow(struct kvm_follow_pfn *foll, kvm_pfn_t *pfn)
> > > {
> > > - unsigned int flags = FOLL_HWPOISON;
> > > + unsigned int flags = FOLL_HWPOISON | FOLL_GET | foll->flags;
> > > struct page *page;
> > > int npages;
> > >
> > > might_sleep();
> > >
> > > - if (writable)
> > > - *writable = write_fault;
> > > -
> > > - if (write_fault)
> > > - flags |= FOLL_WRITE;
> > > - if (async)
> > > - flags |= FOLL_NOWAIT;
> > > - if (interruptible)
> > > - flags |= FOLL_INTERRUPTIBLE;
> > > -
> > > - npages = get_user_pages_unlocked(addr, 1, &page, flags);
> > > + npages = get_user_pages_unlocked(foll->hva, 1, &page, flags);
> > > if (npages != 1)
> > > return npages;
> > >
> > > + foll->writable = (foll->flags & FOLL_WRITE) && foll->allow_write_mapping;
> > > +
> > > /* map read fault as writable if possible */
> > > - if (unlikely(!write_fault) && writable) {
> > > + if (unlikely(!foll->writable) && foll->allow_write_mapping) {
> >
> > I guess !foll->writable should be !(foll->flags & FOLL_WRITE) here.
>
> The two statements are logically equivalent, although I guess using
> !(foll->flags & FOLL_WRITE) may be a little clearer, if a little more
> verbose.
Well, as the comment says, we wanna try to map the read fault as writable
whenever possible. And __gfn_to_pfn_memslot() will only set the FOLL_WRITE
for write faults. So I guess using !foll->writable will not allow this.
Did I miss anything?
> > > +kvm_pfn_t __gfn_to_pfn_memslot(const struct kvm_memory_slot *slot, gfn_t gfn,
> > > + bool atomic, bool interruptible, bool *async,
> > > + bool write_fault, bool *writable, hva_t *hva)
> > > +{
> > > + kvm_pfn_t pfn;
> > > + struct kvm_follow_pfn foll = {
> > > + .slot = slot,
> > > + .gfn = gfn,
> > > + .flags = 0,
> > > + .atomic = atomic,
> > > + .allow_write_mapping = !!writable,
> > > + };
> > > +
> > > + if (write_fault)
> > > + foll.flags |= FOLL_WRITE;
> > > + if (async)
> > > + foll.flags |= FOLL_NOWAIT;
> > > + if (interruptible)
> > > + foll.flags |= FOLL_INTERRUPTIBLE;
> > > +
> > > + pfn = __kvm_follow_pfn(&foll);
> > > + if (pfn == KVM_PFN_ERR_NEEDS_IO) {
> >
> > Could we just use KVM_PFN_ERR_FAULT and foll.flags here? I.e.,
> > if (pfn == KVM_PFN_ERR_FAULT && (foll.flags & FOLL_NOWAIT))?
> > Setting pfn to KVM_PFN_ERR_NEEDS_IO just to indicate an async fault
> > seems unnecessary.
>
> There are the cases where the fault does not fall within a vma or when
> the target vma's flags don't support the fault's access permissions.
> In those cases, continuing to try to resolve the fault won't cause
> problems per-se, but it's wasteful and a bit confusing. Having
> hva_to_pfn detect whether or not it may be possible to resolve the
> fault asynchronously and return KVM_PFN_ERR_NEEDS_IO if so seems like
> a good idea. It also matches what the existing code does.
Got it. Sounds reasonable. And thanks! :)
B.R.
Yu
WARNING: multiple messages have this Message-ID (diff)
From: Yu Zhang <yu.c.zhang@linux.intel.com>
To: David Stevens <stevensd@chromium.org>
Cc: Sean Christopherson <seanjc@google.com>,
Marc Zyngier <maz@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Peter Xu <peterx@redhat.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v7 2/8] KVM: Introduce __kvm_follow_pfn function
Date: Wed, 5 Jul 2023 18:53:43 +0800 [thread overview]
Message-ID: <20230705105343.iounmlflfued7lco@linux.intel.com> (raw)
In-Reply-To: <CAD=HUj6-VbznOOtn5WJee7Of_nh33ygg7_ph2G=hgnvNk_Cbsw@mail.gmail.com>
On Wed, Jul 05, 2023 at 06:22:59PM +0900, David Stevens wrote:
> On Wed, Jul 5, 2023 at 12:10 PM Yu Zhang <yu.c.zhang@linux.intel.com> wrote:
> >
> > > @@ -2514,35 +2512,26 @@ static bool hva_to_pfn_fast(unsigned long addr, bool write_fault,
> > > * The slow path to get the pfn of the specified host virtual address,
> > > * 1 indicates success, -errno is returned if error is detected.
> > > */
> > > -static int hva_to_pfn_slow(unsigned long addr, bool *async, bool write_fault,
> > > - bool interruptible, bool *writable, kvm_pfn_t *pfn)
> > > +static int hva_to_pfn_slow(struct kvm_follow_pfn *foll, kvm_pfn_t *pfn)
> > > {
> > > - unsigned int flags = FOLL_HWPOISON;
> > > + unsigned int flags = FOLL_HWPOISON | FOLL_GET | foll->flags;
> > > struct page *page;
> > > int npages;
> > >
> > > might_sleep();
> > >
> > > - if (writable)
> > > - *writable = write_fault;
> > > -
> > > - if (write_fault)
> > > - flags |= FOLL_WRITE;
> > > - if (async)
> > > - flags |= FOLL_NOWAIT;
> > > - if (interruptible)
> > > - flags |= FOLL_INTERRUPTIBLE;
> > > -
> > > - npages = get_user_pages_unlocked(addr, 1, &page, flags);
> > > + npages = get_user_pages_unlocked(foll->hva, 1, &page, flags);
> > > if (npages != 1)
> > > return npages;
> > >
> > > + foll->writable = (foll->flags & FOLL_WRITE) && foll->allow_write_mapping;
> > > +
> > > /* map read fault as writable if possible */
> > > - if (unlikely(!write_fault) && writable) {
> > > + if (unlikely(!foll->writable) && foll->allow_write_mapping) {
> >
> > I guess !foll->writable should be !(foll->flags & FOLL_WRITE) here.
>
> The two statements are logically equivalent, although I guess using
> !(foll->flags & FOLL_WRITE) may be a little clearer, if a little more
> verbose.
Well, as the comment says, we wanna try to map the read fault as writable
whenever possible. And __gfn_to_pfn_memslot() will only set the FOLL_WRITE
for write faults. So I guess using !foll->writable will not allow this.
Did I miss anything?
> > > +kvm_pfn_t __gfn_to_pfn_memslot(const struct kvm_memory_slot *slot, gfn_t gfn,
> > > + bool atomic, bool interruptible, bool *async,
> > > + bool write_fault, bool *writable, hva_t *hva)
> > > +{
> > > + kvm_pfn_t pfn;
> > > + struct kvm_follow_pfn foll = {
> > > + .slot = slot,
> > > + .gfn = gfn,
> > > + .flags = 0,
> > > + .atomic = atomic,
> > > + .allow_write_mapping = !!writable,
> > > + };
> > > +
> > > + if (write_fault)
> > > + foll.flags |= FOLL_WRITE;
> > > + if (async)
> > > + foll.flags |= FOLL_NOWAIT;
> > > + if (interruptible)
> > > + foll.flags |= FOLL_INTERRUPTIBLE;
> > > +
> > > + pfn = __kvm_follow_pfn(&foll);
> > > + if (pfn == KVM_PFN_ERR_NEEDS_IO) {
> >
> > Could we just use KVM_PFN_ERR_FAULT and foll.flags here? I.e.,
> > if (pfn == KVM_PFN_ERR_FAULT && (foll.flags & FOLL_NOWAIT))?
> > Setting pfn to KVM_PFN_ERR_NEEDS_IO just to indicate an async fault
> > seems unnecessary.
>
> There are the cases where the fault does not fall within a vma or when
> the target vma's flags don't support the fault's access permissions.
> In those cases, continuing to try to resolve the fault won't cause
> problems per-se, but it's wasteful and a bit confusing. Having
> hva_to_pfn detect whether or not it may be possible to resolve the
> fault asynchronously and return KVM_PFN_ERR_NEEDS_IO if so seems like
> a good idea. It also matches what the existing code does.
Got it. Sounds reasonable. And thanks! :)
B.R.
Yu
_______________________________________________
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-07-05 10:53 UTC|newest]
Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-04 7:50 [PATCH v7 0/8] KVM: allow mapping non-refcounted pages David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 1/8] KVM: Assert that a page's refcount is elevated when marking accessed/dirty David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 2/8] KVM: Introduce __kvm_follow_pfn function David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-05 3:10 ` Yu Zhang
2023-07-05 3:10 ` Yu Zhang
2023-07-05 3:10 ` Yu Zhang
2023-07-05 9:22 ` David Stevens
2023-07-05 9:22 ` David Stevens
2023-07-05 9:22 ` David Stevens
2023-07-05 10:53 ` Yu Zhang [this message]
2023-07-05 10:53 ` Yu Zhang
2023-07-05 10:53 ` Yu Zhang
2023-07-06 5:29 ` David Stevens
2023-07-06 5:29 ` David Stevens
2023-07-06 5:29 ` David Stevens
2023-07-06 14:52 ` Yu Zhang
2023-07-06 14:52 ` Yu Zhang
2023-07-06 14:52 ` Yu Zhang
2023-08-04 22:03 ` Sean Christopherson
2023-08-04 22:03 ` Sean Christopherson
2023-08-04 22:03 ` Sean Christopherson
2023-07-05 8:47 ` Zhi Wang
2023-07-05 8:47 ` Zhi Wang
2023-07-05 8:47 ` Zhi Wang
2023-07-05 9:08 ` David Stevens
2023-07-05 9:08 ` David Stevens
2023-07-05 9:08 ` David Stevens
2023-07-11 17:37 ` Zhi Wang
2023-07-11 17:37 ` Zhi Wang
2023-07-11 17:37 ` Zhi Wang
2023-07-06 1:34 ` Isaku Yamahata
2023-07-06 1:34 ` Isaku Yamahata
2023-07-06 1:34 ` Isaku Yamahata
2023-07-06 5:52 ` David Stevens
2023-07-06 5:52 ` David Stevens
2023-07-06 5:52 ` David Stevens
2023-08-04 22:13 ` Sean Christopherson
2023-08-04 22:13 ` Sean Christopherson
2023-08-04 22:13 ` Sean Christopherson
2023-07-04 7:50 ` [PATCH v7 3/8] KVM: Make __kvm_follow_pfn not imply FOLL_GET David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-05 7:23 ` Yu Zhang
2023-07-05 7:23 ` Yu Zhang
2023-07-05 7:23 ` Yu Zhang
2023-07-05 11:56 ` Yu Zhang
2023-07-05 11:56 ` Yu Zhang
2023-07-05 11:56 ` Yu Zhang
2023-07-06 6:09 ` David Stevens
2023-07-06 6:09 ` David Stevens
2023-07-06 6:09 ` David Stevens
2023-07-05 13:19 ` Zhi Wang
2023-07-05 13:19 ` Zhi Wang
2023-07-05 13:19 ` Zhi Wang
2023-07-06 6:49 ` David Stevens
2023-07-06 6:49 ` David Stevens
2023-07-06 6:49 ` David Stevens
2023-07-11 17:33 ` Zhi Wang
2023-07-11 17:33 ` Zhi Wang
2023-07-11 17:33 ` Zhi Wang
2023-07-11 21:59 ` Sean Christopherson
2023-07-11 21:59 ` Sean Christopherson
2023-07-11 21:59 ` Sean Christopherson
2023-09-05 8:26 ` David Stevens
2023-09-05 8:26 ` David Stevens
2023-09-05 8:26 ` David Stevens
2023-09-06 0:45 ` Sean Christopherson
2023-09-06 0:45 ` Sean Christopherson
2023-09-06 0:45 ` Sean Christopherson
2023-09-06 3:24 ` David Stevens
2023-09-06 3:24 ` David Stevens
2023-09-06 3:24 ` David Stevens
2023-09-06 22:03 ` Sean Christopherson
2023-09-06 22:03 ` Sean Christopherson
2023-09-06 22:03 ` Sean Christopherson
2023-07-04 7:50 ` [PATCH v7 4/8] KVM: x86/mmu: Migrate to __kvm_follow_pfn David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-05 8:07 ` Yu Zhang
2023-07-05 8:07 ` Yu Zhang
2023-07-05 8:07 ` Yu Zhang
2023-08-04 22:30 ` Sean Christopherson
2023-08-04 22:30 ` Sean Christopherson
2023-08-04 22:30 ` Sean Christopherson
2023-07-06 1:54 ` Isaku Yamahata
2023-07-06 1:54 ` Isaku Yamahata
2023-07-06 1:54 ` Isaku Yamahata
2023-08-24 8:03 ` David Stevens
2023-08-24 8:03 ` David Stevens
2023-08-24 8:03 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET " David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-05 10:18 ` Yu Zhang
2023-07-05 10:18 ` Yu Zhang
2023-07-05 10:18 ` Yu Zhang
2023-07-05 14:17 ` Yu Zhang
2023-07-05 14:17 ` Yu Zhang
2023-07-05 14:17 ` Yu Zhang
2023-07-06 4:52 ` David Stevens
2023-07-06 4:52 ` David Stevens
2023-07-06 4:52 ` David Stevens
2023-07-06 7:19 ` Yu Zhang
2023-07-06 7:19 ` Yu Zhang
2023-07-06 7:19 ` Yu Zhang
2023-07-06 15:58 ` Isaku Yamahata
2023-07-06 15:58 ` Isaku Yamahata
2023-07-06 15:58 ` Isaku Yamahata
2023-07-07 1:35 ` David Stevens
2023-07-07 1:35 ` David Stevens
2023-07-07 1:35 ` David Stevens
2023-07-10 16:34 ` Isaku Yamahata
2023-07-10 16:34 ` Isaku Yamahata
2023-07-10 16:34 ` Isaku Yamahata
2023-07-11 2:59 ` David Stevens
2023-07-11 2:59 ` David Stevens
2023-07-11 2:59 ` David Stevens
2023-08-04 22:45 ` Sean Christopherson
2023-08-04 22:45 ` Sean Christopherson
2023-08-04 22:45 ` Sean Christopherson
2023-07-05 10:25 ` Yu Zhang
2023-07-05 10:25 ` Yu Zhang
2023-07-05 10:25 ` Yu Zhang
2023-08-24 8:03 ` David Stevens
2023-08-24 8:03 ` David Stevens
2023-08-24 8:03 ` David Stevens
2023-08-24 15:15 ` Sean Christopherson
2023-08-24 15:15 ` Sean Christopherson
2023-08-24 15:15 ` Sean Christopherson
2023-08-25 1:38 ` David Stevens
2023-08-25 1:38 ` David Stevens
2023-08-25 1:38 ` David Stevens
2023-08-31 21:18 ` Sean Christopherson
2023-08-31 21:18 ` Sean Christopherson
2023-08-31 21:18 ` Sean Christopherson
2023-07-06 2:10 ` Isaku Yamahata
2023-07-06 2:10 ` Isaku Yamahata
2023-07-06 2:10 ` Isaku Yamahata
2023-07-06 5:18 ` David Stevens
2023-07-06 5:18 ` David Stevens
2023-07-06 5:18 ` David Stevens
2023-07-19 6:09 ` Yan Zhao
2023-07-19 6:09 ` Yan Zhao
2023-07-19 6:09 ` Yan Zhao
2023-07-19 7:16 ` David Stevens
2023-07-19 7:16 ` David Stevens
2023-07-19 7:16 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 6/8] KVM: arm64: Migrate " David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 7/8] KVM: PPC: " David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` [PATCH v7 8/8] KVM: remove __gfn_to_pfn_memslot David Stevens
2023-07-04 7:50 ` David Stevens
2023-07-04 7:50 ` David Stevens
2023-08-04 22:47 ` [PATCH v7 0/8] KVM: allow mapping non-refcounted pages Sean Christopherson
2023-08-04 22:47 ` Sean Christopherson
2023-08-04 22:47 ` 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=20230705105343.iounmlflfued7lco@linux.intel.com \
--to=yu.c.zhang@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maz@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=peterx@redhat.com \
--cc=seanjc@google.com \
--cc=stevensd@chromium.org \
/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.