From: Harsh Prateek Bora <harshpb@linux.ibm.com>
To: Salil Mehta <salil.mehta@huawei.com>,
"npiggin@gmail.com" <npiggin@gmail.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "danielhb413@gmail.com" <danielhb413@gmail.com>,
"vaibhav@linux.ibm.com" <vaibhav@linux.ibm.com>,
"sbhat@linux.ibm.com" <sbhat@linux.ibm.com>
Subject: Re: [PATCH v2 1/4] accel/kvm: Extract common KVM vCPU {creation, parking} code
Date: Thu, 16 May 2024 20:23:46 +0530 [thread overview]
Message-ID: <937f5dd7-a5eb-415e-b974-cb416f9447b2@linux.ibm.com> (raw)
In-Reply-To: <7a5608c768254869a4a6b68d719c24f1@huawei.com>
Hi Salil,
On 5/16/24 19:05, Salil Mehta wrote:
>
>> From: Harsh Prateek Bora <harshpb@linux.ibm.com>
>> Sent: Thursday, May 16, 2024 2:07 PM
>>
>> Hi Salil,
>>
>> On 5/16/24 17:42, Salil Mehta wrote:
>> > Hi Harsh,
>> >
>> >> From: Harsh Prateek Bora <harshpb@linux.ibm.com>
>> >> Sent: Thursday, May 16, 2024 11:15 AM
>> >>
>> >> Hi Salil,
>> >>
>> >> Thanks for your email.
>> >> Your patch 1/8 is included here based on review comments on my previous
>> >> patch from one of the maintainers in the community and therefore I had
>> >> kept you in CC to be aware of the desire of having this independent patch to
>> >> get merged earlier even if your other patches in the series may go through
>> >> further reviews.
>> >
>> > I really don’t know which discussion are you pointing at? Please
>> > understand you are fixing a bug and we are pushing a feature which has got large series.
>> > It will break the patch-set which is about t be merged.
>> >
>> > There will be significant overhead of testing on us for the work we
>> > have been carrying forward for large time. This will be disruptive. Please dont!
>> >
>>
>> I was referring to the review discussion on my prev patch here:
>> https://lore.kernel.org/qemu-devel/D191D2JFAR7L.2EH4S445M4TGK@gmail.com/
>
>
> Sure, I'm, not sure what this means.
>
No worries. If you had followed the conversation on the review
link I shared, I had made it clear that we are expecting a patch update
from you and it is included here just to facilitate review of additional
patches on the top.
>
>> Although your patch was included with this series only to facilitate review of
>> the additional patches depending on just one of your patch.
>
>
> Generally you rebase your patch-set over the other and clearly state on the cover
> letter that this patch-set is dependent upon such and such patch-set. Just imagine
> if everyone starts to unilaterally pick up patches from each other's patch-set it will
> create a chaos not only for the feature owners but also for the maintainers.
>
Please go through the review discussion on the link I shared above. It
was included on the suggestion of one of the maintainers. However, if
you are going to send v9 soon, everyone would be happy to wait.
>
>>
>> I am not sure what is appearing disruptive here. It is a common practive in
>> the community that maintainer(s) can pick individual patches from the
>> series if it has been vetted by siginificant number of reviewers.
>
>
> Don’t you think this patch-set is asking for acceptance for a patch already
> part of another patch-set which is about to be accepted and is a bigger feature?
> Will it cause maintenance overhead at the last moment? Yes, of course!
No, I dont think so.
>
>
>> However, in this case, since you have mentioned to post next version soon,
>> you need not worry about it as that would be the preferred version for both
>> of the series.
>
>
> Yes, but please understand we are working for the benefit of overall community.
> Please cooperate here.
>
Hope I cleared your confusion. We are waiting to see your v9 soon.
>>
>> >
>> >>
>> >> I am hoping to see your v9 soon and thereafter maintainer(s) may
>> choose to
>> >> pick the latest independent patch if needs to be merged earlier.
>> >
>> >
>> > I don’t think you are understanding what problem it is causing. For
>> > your small bug fix you are causing significant delays at our end.
>> >
>>
>> I hope I clarfied above that including your patch here doesnt delay anything.
>> Hoping to see your v9 soon!
>>
>> Thanks
>> Harsh
>> >
>> > Thanks
>> > Salil.
>> >>
>> >> Thanks for your work and let's be hopeful it gets merged soon.
>> >>
>> >> regards,
>> >> Harsh
>> >>
>> >> On 5/16/24 14:00, Salil Mehta wrote:
>> >> > Hi Harsh,
>> >> >
>> >> > Thanks for your interest in the patch-set but taking away patches like
>> >> > this from other series without any discussion can disrupt others work
>> >> > and its acceptance on time. This is because we will have to put lot of
>> >> > effort in rebasing bigger series and then testing overhead comes
>> along
>> >> > with it.
>> >> >
>> >> > The patch-set (from where this patch has been taken) is part of even
>> >> > bigger series and there have been many people and companies toiling
>> to
>> >> > fix the bugs collectively in that series and for years.
>> >> >
>> >> > I'm about float the V9 version of the Arch agnostic series which this
>> >> > patch is part of and you can rebase your patch-set from there. I'm
>> >> > hopeful that it will get accepted in this cycle.
>> >> >
>> >> >
>> >> > Many thanks
>> >> > Salil.
>> >> >
>> >> >> From: Harsh Prateek Bora <harshpb@linux.ibm.com>
>> >> >> Sent: Thursday, May 16, 2024 6:32 AM
>> >> >>
>> >> >> From: Salil Mehta <salil.mehta@huawei.com>
>> >> >>
>> >> >> KVM vCPU creation is done once during the vCPU realization when
>> >> Qemu
>> >> >> vCPU thread is spawned. This is common to all the architectures as
>> of
>> >> now.
>> >> >>
>> >> >> Hot-unplug of vCPU results in destruction of the vCPU object in
>> QOM
>> >> but
>> >> >> the corresponding KVM vCPU object in the Host KVM is not
>> destroyed
>> >> as
>> >> >> KVM doesn't support vCPU removal. Therefore, its representative
>> KVM
>> >> >> vCPU object/context in Qemu is parked.
>> >> >>
>> >> >> Refactor architecture common logic so that some APIs could be
>> reused
>> >> by
>> >> >> vCPU Hotplug code of some architectures likes ARM, Loongson etc.
>> >> Update
>> >> >> new/old APIs with trace events instead of DPRINTF. No functional
>> >> change is
>> >> >> intended here.
>> >> >>
>> >> >> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
>> >> >> Reviewed-by: Gavin Shan <gshan@redhat.com>
>> >> >> Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
>> >> >> Reviewed-by: Jonathan Cameron
>> <Jonathan.Cameron@huawei.com>
>> >> >> Tested-by: Xianglai Li <lixianglai@loongson.cn>
>> >> >> Tested-by: Miguel Luis <miguel.luis@oracle.com>
>> >> >> Reviewed-by: Shaoqin Huang <shahuang@redhat.com>
>> >> >> [harshpb: fixed rebase failures in include/sysemu/kvm.h]
>> >> >> Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
>> >> >> ---
>> >> >> include/sysemu/kvm.h | 15 ++++++++++
>> >> >> accel/kvm/kvm-all.c | 64
>> ++++++++++++++++++++++++++++++++---
>> >> -----
>> >> >> --
>> >> >> accel/kvm/trace-events | 5 +++-
>> >> >> 3 files changed, 68 insertions(+), 16 deletions(-)
>> >> >>
>> >> >> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h index
>> >> >> eaf801bc93..fa3ec74442 100644
>> >> >> --- a/include/sysemu/kvm.h
>> >> >> +++ b/include/sysemu/kvm.h
>> >> >> @@ -434,6 +434,21 @@ void kvm_set_sigmask_len(KVMState *s,
>> >> unsigned
>> >> >> int sigmask_len);
>> >> >>
>> >> >> int kvm_physical_memory_addr_from_host(KVMState *s, void
>> >> >> *ram_addr,
>> >> >> hwaddr *phys_addr);
>> >> >> +/**
>> >> >> + * kvm_create_vcpu - Gets a parked KVM vCPU or creates a KVM
>> >> vCPU
>> >> >> + * @cpu: QOM CPUState object for which KVM vCPU has to be
>> >> >> fetched/created.
>> >> >> + *
>> >> >> + * @returns: 0 when success, errno (<0) when failed.
>> >> >> + */
>> >> >> +int kvm_create_vcpu(CPUState *cpu);
>> >> >> +
>> >> >> +/**
>> >> >> + * kvm_park_vcpu - Park QEMU KVM vCPU context
>> >> >> + * @cpu: QOM CPUState object for which QEMU KVM vCPU
>> context
>> >> has to
>> >> >> be parked.
>> >> >> + *
>> >> >> + * @returns: none
>> >> >> + */
>> >> >> +void kvm_park_vcpu(CPUState *cpu);
>> >> >>
>> >> >> #endif /* COMPILING_PER_TARGET */
>> >> >>
>> >> >> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index
>> >> >> d7281b93f3..30d42847de 100644
>> >> >> --- a/accel/kvm/kvm-all.c
>> >> >> +++ b/accel/kvm/kvm-all.c
>> >> >> @@ -128,6 +128,7 @@ static QemuMutex kml_slots_lock; #define
>> >> >> kvm_slots_unlock() qemu_mutex_unlock(&kml_slots_lock)
>> >> >>
>> >> >> static void kvm_slot_init_dirty_bitmap(KVMSlot *mem);
>> >> >> +static int kvm_get_vcpu(KVMState *s, unsigned long vcpu_id);
>> >> >>
>> >> >> static inline void kvm_resample_fd_remove(int gsi) { @@ -340,14
>> >> +341,53
>> >> >> @@ err:
>> >> >> return ret;
>> >> >> }
>> >> >>
>> >> >> +void kvm_park_vcpu(CPUState *cpu)
>> >> >> +{
>> >> >> + struct KVMParkedVcpu *vcpu;
>> >> >> +
>> >> >> + trace_kvm_park_vcpu(cpu->cpu_index,
>> kvm_arch_vcpu_id(cpu));
>> >> >> +
>> >> >> + vcpu = g_malloc0(sizeof(*vcpu));
>> >> >> + vcpu->vcpu_id = kvm_arch_vcpu_id(cpu);
>> >> >> + vcpu->kvm_fd = cpu->kvm_fd;
>> >> >> + QLIST_INSERT_HEAD(&kvm_state->kvm_parked_vcpus, vcpu,
>> >> node); }
>> >> >> +
>> >> >> +int kvm_create_vcpu(CPUState *cpu)
>> >> >> +{
>> >> >> + unsigned long vcpu_id = kvm_arch_vcpu_id(cpu);
>> >> >> + KVMState *s = kvm_state;
>> >> >> + int kvm_fd;
>> >> >> +
>> >> >> + trace_kvm_create_vcpu(cpu->cpu_index,
>> kvm_arch_vcpu_id(cpu));
>> >> >> +
>> >> >> + /* check if the KVM vCPU already exist but is parked */
>> >> >> + kvm_fd = kvm_get_vcpu(s, vcpu_id);
>> >> >> + if (kvm_fd < 0) {
>> >> >> + /* vCPU not parked: create a new KVM vCPU */
>> >> >> + kvm_fd = kvm_vm_ioctl(s, KVM_CREATE_VCPU, vcpu_id);
>> >> >> + if (kvm_fd < 0) {
>> >> >> + error_report("KVM_CREATE_VCPU IOCTL failed for vCPU
>> %lu",
>> >> >> vcpu_id);
>> >> >> + return kvm_fd;
>> >> >> + }
>> >> >> + }
>> >> >> +
>> >> >> + cpu->kvm_fd = kvm_fd;
>> >> >> + cpu->kvm_state = s;
>> >> >> + cpu->vcpu_dirty = true;
>> >> >> + cpu->dirty_pages = 0;
>> >> >> + cpu->throttle_us_per_full = 0;
>> >> >> +
>> >> >> + return 0;
>> >> >> +}
>> >> >> +
>> >> >> static int do_kvm_destroy_vcpu(CPUState *cpu) {
>> >> >> KVMState *s = kvm_state;
>> >> >> long mmap_size;
>> >> >> - struct KVMParkedVcpu *vcpu = NULL;
>> >> >> int ret = 0;
>> >> >>
>> >> >> - trace_kvm_destroy_vcpu();
>> >> >> + trace_kvm_destroy_vcpu(cpu->cpu_index,
>> >> kvm_arch_vcpu_id(cpu));
>> >> >>
>> >> >> ret = kvm_arch_destroy_vcpu(cpu);
>> >> >> if (ret < 0) {
>> >> >> @@ -373,10 +413,7 @@ static int do_kvm_destroy_vcpu(CPUState
>> >> *cpu)
>> >> >> }
>> >> >> }
>> >> >>
>> >> >> - vcpu = g_malloc0(sizeof(*vcpu));
>> >> >> - vcpu->vcpu_id = kvm_arch_vcpu_id(cpu);
>> >> >> - vcpu->kvm_fd = cpu->kvm_fd;
>> >> >> - QLIST_INSERT_HEAD(&kvm_state->kvm_parked_vcpus, vcpu,
>> >> node);
>> >> >> + kvm_park_vcpu(cpu);
>> >> >> err:
>> >> >> return ret;
>> >> >> }
>> >> >> @@ -397,6 +434,8 @@ static int kvm_get_vcpu(KVMState *s,
>> unsigned
>> >> long
>> >> >> vcpu_id)
>> >> >> if (cpu->vcpu_id == vcpu_id) {
>> >> >> int kvm_fd;
>> >> >>
>> >> >> + trace_kvm_get_vcpu(vcpu_id);
>> >> >> +
>> >> >> QLIST_REMOVE(cpu, node);
>> >> >> kvm_fd = cpu->kvm_fd;
>> >> >> g_free(cpu);
>> >> >> @@ -404,7 +443,7 @@ static int kvm_get_vcpu(KVMState *s,
>> unsigned
>> >> long
>> >> >> vcpu_id)
>> >> >> }
>> >> >> }
>> >> >>
>> >> >> - return kvm_vm_ioctl(s, KVM_CREATE_VCPU, (void *)vcpu_id);
>> >> >> + return -ENOENT;
>> >> >> }
>> >> >>
>> >> >> int kvm_init_vcpu(CPUState *cpu, Error **errp) @@ -415,19
>> +454,14
>> >> @@
>> >> >> int kvm_init_vcpu(CPUState *cpu, Error **errp)
>> >> >>
>> >> >> trace_kvm_init_vcpu(cpu->cpu_index, kvm_arch_vcpu_id(cpu));
>> >> >>
>> >> >> - ret = kvm_get_vcpu(s, kvm_arch_vcpu_id(cpu));
>> >> >> + ret = kvm_create_vcpu(cpu);
>> >> >> if (ret < 0) {
>> >> >> - error_setg_errno(errp, -ret, "kvm_init_vcpu: kvm_get_vcpu
>> failed
>> >> >> (%lu)",
>> >> >> + error_setg_errno(errp, -ret,
>> >> >> + "kvm_init_vcpu: kvm_create_vcpu failed (%lu)",
>> >> >> kvm_arch_vcpu_id(cpu));
>> >> >> goto err;
>> >> >> }
>> >> >>
>> >> >> - cpu->kvm_fd = ret;
>> >> >> - cpu->kvm_state = s;
>> >> >> - cpu->vcpu_dirty = true;
>> >> >> - cpu->dirty_pages = 0;
>> >> >> - cpu->throttle_us_per_full = 0;
>> >> >> -
>> >> >> mmap_size = kvm_ioctl(s, KVM_GET_VCPU_MMAP_SIZE, 0);
>> >> >> if (mmap_size < 0) {
>> >> >> ret = mmap_size;
>> >> >> diff --git a/accel/kvm/trace-events b/accel/kvm/trace-events index
>> >> >> 681ccb667d..75c1724e78 100644
>> >> >> --- a/accel/kvm/trace-events
>> >> >> +++ b/accel/kvm/trace-events
>> >> >> @@ -9,6 +9,10 @@ kvm_device_ioctl(int fd, int type, void *arg)
>> "dev fd
>> >> %d,
>> >> >> type 0x%x, arg %p"
>> >> >> kvm_failed_reg_get(uint64_t id, const char *msg) "Warning:
>> Unable to
>> >> >> retrieve ONEREG %" PRIu64 " from KVM: %s"
>> >> >> kvm_failed_reg_set(uint64_t id, const char *msg) "Warning:
>> Unable to
>> >> set
>> >> >> ONEREG %" PRIu64 " to KVM: %s"
>> >> >> kvm_init_vcpu(int cpu_index, unsigned long arch_cpu_id) "index:
>> %d
>> >> id:
>> >> >> %lu"
>> >> >> +kvm_create_vcpu(int cpu_index, unsigned long arch_cpu_id)
>> "index:
>> >> %d
>> >> >> id: %lu"
>> >> >> +kvm_get_vcpu(unsigned long arch_cpu_id) "id: %lu"
>> >> >> +kvm_destroy_vcpu(int cpu_index, unsigned long arch_cpu_id)
>> "index:
>> >> %d
>> >> >> id: %lu"
>> >> >> +kvm_park_vcpu(int cpu_index, unsigned long arch_cpu_id)
>> "index: %d
>> >> id:
>> >> >> %lu"
>> >> >> kvm_irqchip_commit_routes(void) ""
>> >> >> kvm_irqchip_add_msi_route(char *name, int vector, int virq) "dev
>> %s
>> >> >> vector %d virq %d"
>> >> >> kvm_irqchip_update_msi_route(int virq) "Updating MSI route
>> >> virq=%d"
>> >> >> @@ -25,7 +29,6 @@ kvm_dirty_ring_reaper(const char *s) "%s"
>> >> >> kvm_dirty_ring_reap(uint64_t count, int64_t t) "reaped %"PRIu64"
>> >> pages
>> >> >> (took %"PRIi64" us)"
>> >> >> kvm_dirty_ring_reaper_kick(const char *reason) "%s"
>> >> >> kvm_dirty_ring_flush(int finished) "%d"
>> >> >> -kvm_destroy_vcpu(void) ""
>> >> >> kvm_failed_get_vcpu_mmap_size(void) ""
>> >> >> kvm_cpu_exec(void) ""
>> >> >> kvm_interrupt_exit_request(void) ""
>> >> >> --
>> >> >> 2.39.3
>> >> >
next prev parent reply other threads:[~2024-05-16 14:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 5:32 [PATCH v2 0/4] target/ppc: vcpu hotplug failure handling fixes Harsh Prateek Bora
2024-05-16 5:32 ` [PATCH v2 1/4] accel/kvm: Extract common KVM vCPU {creation, parking} code Harsh Prateek Bora
2024-05-16 8:30 ` Salil Mehta via
2024-05-16 10:15 ` Harsh Prateek Bora
2024-05-16 12:12 ` Salil Mehta via
2024-05-16 13:06 ` Harsh Prateek Bora
2024-05-16 13:35 ` Salil Mehta via
[not found] ` <5bd52d8f5aaa49d6bc0ae419bb16c27c@huawei.com>
2024-05-16 14:19 ` Salil Mehta
2024-05-16 14:53 ` Harsh Prateek Bora [this message]
2024-05-17 3:44 ` Nicholas Piggin
2024-05-17 10:13 ` Salil Mehta via
2024-05-16 5:32 ` [PATCH v2 2/4] accel/kvm: Introduce kvm_create_and_park_vcpu() helper Harsh Prateek Bora
2024-05-16 5:32 ` [PATCH v2 3/4] cpu-common.c: export cpu_get_free_index to be reused later Harsh Prateek Bora
2024-05-16 5:32 ` [PATCH v2 4/4] target/ppc: handle vcpu hotplug failure gracefully Harsh Prateek Bora
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=937f5dd7-a5eb-415e-b974-cb416f9447b2@linux.ibm.com \
--to=harshpb@linux.ibm.com \
--cc=danielhb413@gmail.com \
--cc=npiggin@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=salil.mehta@huawei.com \
--cc=sbhat@linux.ibm.com \
--cc=vaibhav@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).