From: Salil Mehta via <qemu-devel@nongnu.org> To: David Hildenbrand <david@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "qemu-arm@nongnu.org" <qemu-arm@nongnu.org> Cc: "maz@kernel.org" <maz@kernel.org>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, Jonathan Cameron <jonathan.cameron@huawei.com>, "lpieralisi@kernel.org" <lpieralisi@kernel.org>, "peter.maydell@linaro.org" <peter.maydell@linaro.org>, "richard.henderson@linaro.org" <richard.henderson@linaro.org>, "imammedo@redhat.com" <imammedo@redhat.com>, "andrew.jones@linux.dev" <andrew.jones@linux.dev>, "philmd@linaro.org" <philmd@linaro.org>, "eric.auger@redhat.com" <eric.auger@redhat.com>, "oliver.upton@linux.dev" <oliver.upton@linux.dev>, "pbonzini@redhat.com" <pbonzini@redhat.com>, "mst@redhat.com" <mst@redhat.com>, "will@kernel.org" <will@kernel.org>, "gshan@redhat.com" <gshan@redhat.com>, "rafael@kernel.org" <rafael@kernel.org>, "alex.bennee@linaro.org" <alex.bennee@linaro.org>, "linux@armlinux.org.uk" <linux@armlinux.org.uk>, "darren@os.amperecomputing.com" <darren@os.amperecomputing.com>, "ilkka@os.amperecomputing.com" <ilkka@os.amperecomputing.com>, "vishnu@os.amperecomputing.com" <vishnu@os.amperecomputing.com>, "karl.heubaum@oracle.com" <karl.heubaum@oracle.com>, "miguel.luis@oracle.com" <miguel.luis@oracle.com>, "salil.mehta@opnsrc.net" <salil.mehta@opnsrc.net>, zhukeqian <zhukeqian1@huawei.com>, "wangxiongfeng (C)" <wangxiongfeng2@huawei.com>, "wangyanan (Y)" <wangyanan55@huawei.com>, "jiakernel2@gmail.com" <jiakernel2@gmail.com>, "maobibo@loongson.cn" <maobibo@loongson.cn>, "lixianglai@loongson.cn" <lixianglai@loongson.cn>, Linuxarm <linuxarm@huawei.com> Subject: RE: [PATCH V3 01/10] accel/kvm: Extract common KVM vCPU {creation,parking} code Date: Mon, 9 Oct 2023 15:10:49 +0000 [thread overview] Message-ID: <0c972e213f9a46c3a595dc7f933046aa@huawei.com> (raw) In-Reply-To: <ae2e0fc1-7967-2bae-e4fa-b4d886ba4671@redhat.com> > From: David Hildenbrand <david@redhat.com> > Sent: Monday, October 9, 2023 3:11 PM > To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org; qemu- > arm@nongnu.org > Cc: maz@kernel.org; jean-philippe@linaro.org; Jonathan Cameron > <jonathan.cameron@huawei.com>; lpieralisi@kernel.org; > peter.maydell@linaro.org; richard.henderson@linaro.org; > imammedo@redhat.com; andrew.jones@linux.dev; philmd@linaro.org; > eric.auger@redhat.com; oliver.upton@linux.dev; pbonzini@redhat.com; > mst@redhat.com; will@kernel.org; gshan@redhat.com; rafael@kernel.org; > alex.bennee@linaro.org; linux@armlinux.org.uk; > darren@os.amperecomputing.com; ilkka@os.amperecomputing.com; > vishnu@os.amperecomputing.com; karl.heubaum@oracle.com; > miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian > <zhukeqian1@huawei.com>; wangxiongfeng (C) <wangxiongfeng2@huawei.com>; > wangyanan (Y) <wangyanan55@huawei.com>; jiakernel2@gmail.com; > maobibo@loongson.cn; lixianglai@loongson.cn; Linuxarm <linuxarm@huawei.com> > Subject: Re: [PATCH V3 01/10] accel/kvm: Extract common KVM vCPU > {creation,parking} code > > On 09.10.23 15:42, Salil Mehta wrote: > > Hi David, > > Thanks for the review. > > > >> From: David Hildenbrand <david@redhat.com> > >> Sent: Monday, October 9, 2023 1:21 PM > >> To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org; qemu-arm@nongnu.org > >> Cc: maz@kernel.org; jean-philippe@linaro.org; Jonathan Cameron > >> <jonathan.cameron@huawei.com>; lpieralisi@kernel.org; > >> peter.maydell@linaro.org; richard.henderson@linaro.org; > >> imammedo@redhat.com; andrew.jones@linux.dev; philmd@linaro.org; > >> eric.auger@redhat.com; oliver.upton@linux.dev; pbonzini@redhat.com; > >> mst@redhat.com; will@kernel.org; gshan@redhat.com; rafael@kernel.org; > >> alex.bennee@linaro.org; linux@armlinux.org.uk; > >> darren@os.amperecomputing.com; ilkka@os.amperecomputing.com; > >> vishnu@os.amperecomputing.com; karl.heubaum@oracle.com; > >> miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian > >> <zhukeqian1@huawei.com>; wangxiongfeng (C) <wangxiongfeng2@huawei.com>; > >> wangyanan (Y) <wangyanan55@huawei.com>; jiakernel2@gmail.com; > >> maobibo@loongson.cn; lixianglai@loongson.cn; Linuxarm > <linuxarm@huawei.com> > >> Subject: Re: [PATCH V3 01/10] accel/kvm: Extract common KVM vCPU > >> {creation,parking} code > >> > >> On 09.10.23 13:28, Salil Mehta wrote: > >>> KVM vCPU creation is done once during the initialization of the VM when Qemu > >>> thread is spawned. This is common to all the architectures. > >>> > >>> 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 and its > >>> representative KVM vCPU object/context in Qemu is parked. > >>> > >>> Refactor common logic so that some APIs could be reused by vCPU Hotplug code. > >>> > >>> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> > >> > >> [...] > >> > >>> > >>> int kvm_init_vcpu(CPUState *cpu, Error **errp) > >>> @@ -395,19 +434,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)", > >> > >> Unrelated change. > > > > > > It is related. I think you missed kvm_get_vcpu -> kvm_create_vcpu change > > in the string. > > Indeed, I did :) > > > > > > >>> 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 399aaeb0ec..08e2dc253f 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) "creating KVM cpu: cpu_index: %d arch vcpu-id: %lu" > >>> +kvm_get_vcpu(unsigned long arch_cpu_id) "unparking KVM vcpu: arch vcpu-id: %lu" > >>> +kvm_destroy_vcpu(int cpu_index, unsigned long arch_cpu_id) "destroy vcpu: cpu_index: %d arch vcpu-id: %lu" > >>> +kvm_park_vcpu(int cpu_index, unsigned long arch_cpu_id) "parking KVM vcpu: cpu_index: %d arch vcpu-id: %lu" > >> > >> It's a bit confusing that there is now > >> > >> 1) create (create new or return parked) > >> 2) destroy (cleanup + park) > >> 3) park (park only) > >> > >> Why would one use 2) instead of 3) or the other way around? But I > >> suspect that kvm_destroy_vcpu() is only supposed to be a KVM-internal > >> helper ... > > > > kvm_destroy_vcpu is more than just parking: > > > > 1. Arch destroy vcpu > > 2. Unmap cpu->kvm_run > > 3. Parking logic > > > > To support virtual CPU Hotplug on ARM platforms we pre-create all > > the KVM vCPUs but their corresponding Qemu threads are not spawned > > (and hence cpu->kvm_run is not mapped). Unplugged vCPUs remains > > parked in the list. Hence, only step-3 is required. > > IIUC, your current flow is going to be > > 1) Create > 2) Park > 3) Create [which ends up reusing the parked VCPU] > 4) Destroy [when unplugging the CPU] In the ARM specific code, Yes. > If that's the case, that API really is suboptimal. > > What speaks against an API that models 1) and 2) in a single step API is generic and is part of architecture agnostic code. > > kvm_precreate_vcpu pre-creation is very much specific to ARM right now. I am not sure if it is right to have an API with this name in the code which is common to other architectures. > kvm_create_vcpu > kvm_destroy_vcpu > > One could even make kvm_create_vcpu() fail on ARM if the VCPU hasn't > been pre-created. Right now, we abort the CPU initialization process if this happens. I am planning to change abort() into 'fatal_error' in RFC V3 though. > > Or did I get it all wrong? :) I won't say that it is just another point of view which is absolutely fine. But I would like to stick to current APIs. Thanks Salil.
WARNING: multiple messages have this Message-ID (diff)
From: Salil Mehta <salil.mehta@huawei.com> To: David Hildenbrand <david@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "qemu-arm@nongnu.org" <qemu-arm@nongnu.org> Cc: "maz@kernel.org" <maz@kernel.org>, "jean-philippe@linaro.org" <jean-philippe@linaro.org>, Jonathan Cameron <jonathan.cameron@huawei.com>, "lpieralisi@kernel.org" <lpieralisi@kernel.org>, "peter.maydell@linaro.org" <peter.maydell@linaro.org>, "richard.henderson@linaro.org" <richard.henderson@linaro.org>, "imammedo@redhat.com" <imammedo@redhat.com>, "andrew.jones@linux.dev" <andrew.jones@linux.dev>, "philmd@linaro.org" <philmd@linaro.org>, "eric.auger@redhat.com" <eric.auger@redhat.com>, "oliver.upton@linux.dev" <oliver.upton@linux.dev>, "pbonzini@redhat.com" <pbonzini@redhat.com>, "mst@redhat.com" <mst@redhat.com>, "will@kernel.org" <will@kernel.org>, "gshan@redhat.com" <gshan@redhat.com>, "rafael@kernel.org" <rafael@kernel.org>, "alex.bennee@linaro.org" <alex.bennee@linaro.org>, "linux@armlinux.org.uk" <linux@armlinux.org.uk>, "darren@os.amperecomputing.com" <darren@os.amperecomputing.com>, "ilkka@os.amperecomputing.com" <ilkka@os.amperecomputing.com>, "vishnu@os.amperecomputing.com" <vishnu@os.amperecomputing.com>, "karl.heubaum@oracle.com" <karl.heubaum@oracle.com>, "miguel.luis@oracle.com" <miguel.luis@oracle.com>, "salil.mehta@opnsrc.net" <salil.mehta@opnsrc.net>, zhukeqian <zhukeqian1@huawei.com>, "wangxiongfeng (C)" <wangxiongfeng2@huawei.com>, "wangyanan (Y)" <wangyanan55@huawei.com>, "jiakernel2@gmail.com" <jiakernel2@gmail.com>, "maobibo@loongson.cn" <maobibo@loongson.cn>, "lixianglai@loongson.cn" <lixianglai@loongson.cn>, Linuxarm <linuxarm@huawei.com> Subject: RE: [PATCH V3 01/10] accel/kvm: Extract common KVM vCPU {creation,parking} code Date: Mon, 9 Oct 2023 15:10:49 +0000 [thread overview] Message-ID: <0c972e213f9a46c3a595dc7f933046aa@huawei.com> (raw) Message-ID: <20231009151049.afaDFvag4RnRKKthsghYF25BERApiDu08u9Mwx6h5Mw@z> (raw) In-Reply-To: <ae2e0fc1-7967-2bae-e4fa-b4d886ba4671@redhat.com> > From: David Hildenbrand <david@redhat.com> > Sent: Monday, October 9, 2023 3:11 PM > To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org; qemu- > arm@nongnu.org > Cc: maz@kernel.org; jean-philippe@linaro.org; Jonathan Cameron > <jonathan.cameron@huawei.com>; lpieralisi@kernel.org; > peter.maydell@linaro.org; richard.henderson@linaro.org; > imammedo@redhat.com; andrew.jones@linux.dev; philmd@linaro.org; > eric.auger@redhat.com; oliver.upton@linux.dev; pbonzini@redhat.com; > mst@redhat.com; will@kernel.org; gshan@redhat.com; rafael@kernel.org; > alex.bennee@linaro.org; linux@armlinux.org.uk; > darren@os.amperecomputing.com; ilkka@os.amperecomputing.com; > vishnu@os.amperecomputing.com; karl.heubaum@oracle.com; > miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian > <zhukeqian1@huawei.com>; wangxiongfeng (C) <wangxiongfeng2@huawei.com>; > wangyanan (Y) <wangyanan55@huawei.com>; jiakernel2@gmail.com; > maobibo@loongson.cn; lixianglai@loongson.cn; Linuxarm <linuxarm@huawei.com> > Subject: Re: [PATCH V3 01/10] accel/kvm: Extract common KVM vCPU > {creation,parking} code > > On 09.10.23 15:42, Salil Mehta wrote: > > Hi David, > > Thanks for the review. > > > >> From: David Hildenbrand <david@redhat.com> > >> Sent: Monday, October 9, 2023 1:21 PM > >> To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org; qemu-arm@nongnu.org > >> Cc: maz@kernel.org; jean-philippe@linaro.org; Jonathan Cameron > >> <jonathan.cameron@huawei.com>; lpieralisi@kernel.org; > >> peter.maydell@linaro.org; richard.henderson@linaro.org; > >> imammedo@redhat.com; andrew.jones@linux.dev; philmd@linaro.org; > >> eric.auger@redhat.com; oliver.upton@linux.dev; pbonzini@redhat.com; > >> mst@redhat.com; will@kernel.org; gshan@redhat.com; rafael@kernel.org; > >> alex.bennee@linaro.org; linux@armlinux.org.uk; > >> darren@os.amperecomputing.com; ilkka@os.amperecomputing.com; > >> vishnu@os.amperecomputing.com; karl.heubaum@oracle.com; > >> miguel.luis@oracle.com; salil.mehta@opnsrc.net; zhukeqian > >> <zhukeqian1@huawei.com>; wangxiongfeng (C) <wangxiongfeng2@huawei.com>; > >> wangyanan (Y) <wangyanan55@huawei.com>; jiakernel2@gmail.com; > >> maobibo@loongson.cn; lixianglai@loongson.cn; Linuxarm > <linuxarm@huawei.com> > >> Subject: Re: [PATCH V3 01/10] accel/kvm: Extract common KVM vCPU > >> {creation,parking} code > >> > >> On 09.10.23 13:28, Salil Mehta wrote: > >>> KVM vCPU creation is done once during the initialization of the VM when Qemu > >>> thread is spawned. This is common to all the architectures. > >>> > >>> 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 and its > >>> representative KVM vCPU object/context in Qemu is parked. > >>> > >>> Refactor common logic so that some APIs could be reused by vCPU Hotplug code. > >>> > >>> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> > >> > >> [...] > >> > >>> > >>> int kvm_init_vcpu(CPUState *cpu, Error **errp) > >>> @@ -395,19 +434,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)", > >> > >> Unrelated change. > > > > > > It is related. I think you missed kvm_get_vcpu -> kvm_create_vcpu change > > in the string. > > Indeed, I did :) > > > > > > >>> 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 399aaeb0ec..08e2dc253f 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) "creating KVM cpu: cpu_index: %d arch vcpu-id: %lu" > >>> +kvm_get_vcpu(unsigned long arch_cpu_id) "unparking KVM vcpu: arch vcpu-id: %lu" > >>> +kvm_destroy_vcpu(int cpu_index, unsigned long arch_cpu_id) "destroy vcpu: cpu_index: %d arch vcpu-id: %lu" > >>> +kvm_park_vcpu(int cpu_index, unsigned long arch_cpu_id) "parking KVM vcpu: cpu_index: %d arch vcpu-id: %lu" > >> > >> It's a bit confusing that there is now > >> > >> 1) create (create new or return parked) > >> 2) destroy (cleanup + park) > >> 3) park (park only) > >> > >> Why would one use 2) instead of 3) or the other way around? But I > >> suspect that kvm_destroy_vcpu() is only supposed to be a KVM-internal > >> helper ... > > > > kvm_destroy_vcpu is more than just parking: > > > > 1. Arch destroy vcpu > > 2. Unmap cpu->kvm_run > > 3. Parking logic > > > > To support virtual CPU Hotplug on ARM platforms we pre-create all > > the KVM vCPUs but their corresponding Qemu threads are not spawned > > (and hence cpu->kvm_run is not mapped). Unplugged vCPUs remains > > parked in the list. Hence, only step-3 is required. > > IIUC, your current flow is going to be > > 1) Create > 2) Park > 3) Create [which ends up reusing the parked VCPU] > 4) Destroy [when unplugging the CPU] In the ARM specific code, Yes. > If that's the case, that API really is suboptimal. > > What speaks against an API that models 1) and 2) in a single step API is generic and is part of architecture agnostic code. > > kvm_precreate_vcpu pre-creation is very much specific to ARM right now. I am not sure if it is right to have an API with this name in the code which is common to other architectures. > kvm_create_vcpu > kvm_destroy_vcpu > > One could even make kvm_create_vcpu() fail on ARM if the VCPU hasn't > been pre-created. Right now, we abort the CPU initialization process if this happens. I am planning to change abort() into 'fatal_error' in RFC V3 though. > > Or did I get it all wrong? :) I won't say that it is just another point of view which is absolutely fine. But I would like to stick to current APIs. Thanks Salil.
next prev parent reply other threads:[~2023-10-09 15:11 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-09 11:28 [PATCH V3 00/10] Add architecture agnostic code to support vCPU Hotplug Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 01/10] accel/kvm: Extract common KVM vCPU {creation, parking} code Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 12:20 ` [PATCH V3 01/10] accel/kvm: Extract common KVM vCPU {creation,parking} code David Hildenbrand 2023-10-09 13:42 ` Salil Mehta via 2023-10-09 13:42 ` Salil Mehta 2023-10-09 14:11 ` David Hildenbrand 2023-10-09 15:10 ` Salil Mehta via [this message] 2023-10-09 15:10 ` Salil Mehta 2023-10-09 15:21 ` David Hildenbrand 2023-10-09 15:34 ` Salil Mehta via 2023-10-09 15:34 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 02/10] hw/acpi: Move CPU ctrl-dev MMIO region len macro to common header file Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 12:21 ` David Hildenbrand 2023-10-09 13:43 ` Salil Mehta via 2023-10-09 13:43 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 03/10] hw/acpi: Add ACPI CPU hotplug init stub Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 12:22 ` David Hildenbrand 2023-10-09 13:49 ` Salil Mehta via 2023-10-09 13:49 ` Salil Mehta 2023-10-09 13:55 ` David Hildenbrand 2023-10-09 15:45 ` Salil Mehta via 2023-10-09 15:45 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 04/10] hw/acpi: Init GED framework with cpu hotplug events Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 12:26 ` David Hildenbrand 2023-10-09 14:12 ` Salil Mehta via 2023-10-09 14:12 ` Salil Mehta 2023-10-09 14:14 ` David Hildenbrand 2023-10-09 15:42 ` Salil Mehta via 2023-10-09 15:42 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 05/10] hw/acpi: Update CPUs AML with cpu-(ctrl)dev change Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 06/10] hw/acpi: Update GED _EVT method AML with CPU scan Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 07/10] hw/acpi: Update ACPI GED framework to support vCPU Hotplug Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 08/10] physmem: Add helper function to destroy CPU AddressSpace Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 09/10] gdbstub: Add helper function to unregister GDB register space Salil Mehta via 2023-10-09 11:28 ` Salil Mehta 2023-10-09 11:28 ` [PATCH V3 10/10] target/arm/kvm: Write CPU state back to KVM on reset Salil Mehta via 2023-10-09 11:28 ` Salil Mehta
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=0c972e213f9a46c3a595dc7f933046aa@huawei.com \ --to=qemu-devel@nongnu.org \ --cc=alex.bennee@linaro.org \ --cc=andrew.jones@linux.dev \ --cc=darren@os.amperecomputing.com \ --cc=david@redhat.com \ --cc=eric.auger@redhat.com \ --cc=gshan@redhat.com \ --cc=ilkka@os.amperecomputing.com \ --cc=imammedo@redhat.com \ --cc=jean-philippe@linaro.org \ --cc=jiakernel2@gmail.com \ --cc=jonathan.cameron@huawei.com \ --cc=karl.heubaum@oracle.com \ --cc=linux@armlinux.org.uk \ --cc=linuxarm@huawei.com \ --cc=lixianglai@loongson.cn \ --cc=lpieralisi@kernel.org \ --cc=maobibo@loongson.cn \ --cc=maz@kernel.org \ --cc=miguel.luis@oracle.com \ --cc=mst@redhat.com \ --cc=oliver.upton@linux.dev \ --cc=pbonzini@redhat.com \ --cc=peter.maydell@linaro.org \ --cc=philmd@linaro.org \ --cc=qemu-arm@nongnu.org \ --cc=rafael@kernel.org \ --cc=richard.henderson@linaro.org \ --cc=salil.mehta@huawei.com \ --cc=salil.mehta@opnsrc.net \ --cc=vishnu@os.amperecomputing.com \ --cc=wangxiongfeng2@huawei.com \ --cc=wangyanan55@huawei.com \ --cc=will@kernel.org \ --cc=zhukeqian1@huawei.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: linkBe 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).