May 2021 - Linuxarm - mailweb.openeuler.org

[PATCH 0/5] Use pm_runtime_resume_and_get()
by Tian Tao 20 May '21

20 May '21

patch#1,#2,#3,#4,#5 use pm_runtime_resume_and_get() to replace pm_runtime_get_sync and pm_runtime_put_noidle. This change is just to simplify the code, no actual functional changes. Tian Tao (5): spi: Use pm_runtime_resume_and_get() to replace open coding spi: spi-mem: Use pm_runtime_resume_and_get() to replace open coding spi: imx: Use pm_runtime_resume_and_get() to replace open coding spi: spi-ti-qspi: Use pm_runtime_resume_and_get() to replace open coding spi: sprd: Use pm_runtime_resume_and_get() to replace open coding drivers/spi/spi-imx.c | 6 ++---- drivers/spi/spi-mem.c | 3 +-- drivers/spi/spi-sprd.c | 3 +-- drivers/spi/spi-ti-qspi.c | 3 +-- drivers/spi/spi.c | 9 +++------ 5 files changed, 8 insertions(+), 16 deletions(-) -- 2.7.4

2 9

[PATCH] spi: Use pm_runtime_resume_and_get() to replace open coding
by Tian Tao 20 May '21

20 May '21

Found using coccicheck script under review at: https://lore.kernel.org/lkml/20210427141946.2478411-1-Julia.Lawall@inria.fr/ Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- drivers/spi/spi.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 57120de..2664b4a 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1486,9 +1486,8 @@ static void __spi_pump_messages(struct spi_controller *ctlr, bool in_kthread) mutex_lock(&ctlr->io_mutex); if (!was_busy && ctlr->auto_runtime_pm) { - ret = pm_runtime_get_sync(ctlr->dev.parent); + ret = pm_runtime_resume_and_get(ctlr->dev.parent); if (ret < 0) { - pm_runtime_put_noidle(ctlr->dev.parent); dev_err(&ctlr->dev, "Failed to power device: %d\n", ret); mutex_unlock(&ctlr->io_mutex); @@ -3426,10 +3425,9 @@ int spi_setup(struct spi_device *spi) } if (spi->controller->auto_runtime_pm && spi->controller->set_cs) { - status = pm_runtime_get_sync(spi->controller->dev.parent); + status = pm_runtime_resume_and_get(spi->controller->dev.parent); if (status < 0) { mutex_unlock(&spi->controller->io_mutex); - pm_runtime_put_noidle(spi->controller->dev.parent); dev_err(&spi->controller->dev, "Failed to power device: %d\n", status); return status; @@ -3491,10 +3489,9 @@ int spi_set_cs_timing(struct spi_device *spi, struct spi_delay *setup, mutex_lock(&spi->controller->io_mutex); if (spi->controller->auto_runtime_pm) { - status = pm_runtime_get_sync(parent); + status = pm_runtime_resume_and_get(parent); if (status < 0) { mutex_unlock(&spi->controller->io_mutex); - pm_runtime_put_noidle(parent); dev_err(&spi->controller->dev, "Failed to power device: %d\n", status); return status; -- 2.7.4

2 1

[RFC 1/1] kernfs: Remove the limit of pagesize in the read of sysfs
by Tian Tao 20 May '21

20 May '21

Currently we use sysfs to display cpu topology, but when the number of cpus is very large, it may exceed a pagesize, so here we remove the pagesize limit from the read function first. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- fs/kernfs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c index c757193..da25e94 100644 --- a/fs/kernfs/file.c +++ b/fs/kernfs/file.c @@ -184,7 +184,7 @@ static const struct seq_operations kernfs_seq_ops = { static ssize_t kernfs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter) { struct kernfs_open_file *of = kernfs_of(iocb->ki_filp); - ssize_t len = min_t(size_t, iov_iter_count(iter), PAGE_SIZE); + ssize_t len = iov_iter_count(iter); const struct kernfs_ops *ops; char *buf; -- 2.7.4

1 0

[PATCH v2] topology: use bin_attribute to avoid buff overflow
by Tian Tao 19 May '21

19 May '21

Use bin_attribute to display thread_siblings/core_cpus/core_siblings, die_cpus/package_cpus/book_siblings/drawer_siblings,avoiding NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- v2: rewrite the function name##_read --- drivers/base/topology.c | 57 ++++++++++++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..1b74ff5 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -14,6 +14,8 @@ #include <linux/hardirq.h> #include <linux/topology.h> +#define BUFF_SIZE ((NR_CPUS/32)*9) + #define define_id_show_func(name) \ static ssize_t name##_show(struct device *dev, \ struct device_attribute *attr, char *buf) \ @@ -21,11 +23,16 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + char temp[BUFF_SIZE] = {0}; \ + scnprintf(temp, BUFF_SIZE, "%*pb\n", nr_cpu_ids, \ + cpumask_bits(topology_##mask(dev->id))); \ + return memory_read_from_buffer(buf, count, &off, temp, BUFF_SIZE); \ } #define define_siblings_show_list(name, mask) \ @@ -37,7 +44,7 @@ static ssize_t name##_list_show(struct device *dev, \ } #define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ + define_siblings_read(name, mask); \ define_siblings_show_list(name, mask) define_id_show_func(physical_package_id); @@ -50,30 +57,30 @@ define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); +static BIN_ATTR_RO(thread_siblings, 0); static DEVICE_ATTR_RO(thread_siblings_list); define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); +static BIN_ATTR_RO(core_cpus, 0); static DEVICE_ATTR_RO(core_cpus_list); define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); +static BIN_ATTR_RO(core_siblings, 0); static DEVICE_ATTR_RO(core_siblings_list); define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); +static BIN_ATTR_RO(die_cpus, 0); static DEVICE_ATTR_RO(die_cpus_list); define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); +static BIN_ATTR_RO(package_cpus, 0); static DEVICE_ATTR_RO(package_cpus_list); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); +static BIN_ATTR_RO(book_siblings, 0); static DEVICE_ATTR_RO(book_siblings_list); #endif @@ -81,32 +88,41 @@ static DEVICE_ATTR_RO(book_siblings_list); define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); +static BIN_ATTR_RO(drawer_siblings, 0); static DEVICE_ATTR_RO(drawer_siblings_list); #endif + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_thread_siblings, + &bin_attr_core_cpus, + &bin_attr_core_siblings, + &bin_attr_die_cpus, + &bin_attr_package_cpus, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, +#endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, +#endif + NULL, +}; + static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, &dev_attr_drawer_siblings_list.attr, #endif NULL @@ -114,6 +130,7 @@ static struct attribute *default_attrs[] = { static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

2 1

Re: [RFC PATCH v2 5/6] hw/arm/virt-acpi-build: Add PPTT table
by Salil Mehta 19 May '21

19 May '21

> From: Qemu-arm [mailto:qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org] > On Behalf Of wangyanan (Y) > Sent: Thursday, May 13, 2021 6:10 AM > > Hi Drew, > > I got a question below, and hope your reply. Thanks! > On 2021/4/13 16:07, Yanan Wang wrote: > > Add the Processor Properties Topology Table (PPTT) to present > > CPU topology information to ACPI guests. Note, while a DT boot > > Linux guest with a non-flat CPU topology will see socket and > > core IDs being sequential integers starting from zero, e.g. > > with -smp 4,sockets=2,cores=2,threads=1 > > > > a DT boot produces > > > > cpu: 0 package_id: 0 core_id: 0 > > cpu: 1 package_id: 0 core_id: 1 > > cpu: 2 package_id: 1 core_id: 0 > > cpu: 3 package_id: 1 core_id: 1 > > > > an ACPI boot produces > > > > cpu: 0 package_id: 36 core_id: 0 > > cpu: 1 package_id: 36 core_id: 1 > > cpu: 2 package_id: 96 core_id: 2 > > cpu: 3 package_id: 96 core_id: 3 > > > > This is due to several reasons: > > > > 1) DT cpu nodes do not have an equivalent field to what the PPTT > > ACPI Processor ID must be, i.e. something equal to the MADT CPU > > UID or equal to the UID of an ACPI processor container. In both > > ACPI cases those are platform dependant IDs assigned by the > > vendor. > > > > 2) While QEMU is the vendor for a guest, if the topology specifies > > SMT (> 1 thread), then, with ACPI, it is impossible to assign a > > core-id the same value as a package-id, thus it is not possible > > to have package-id=0 and core-id=0. This is because package and > > core containers must be in the same ACPI namespace and therefore > > must have unique UIDs. > > > > 3) ACPI processor containers are not required for PPTT tables to > > be used and, due to the limitations of which IDs are selected > > described above in (2), they are not helpful for QEMU, so we > > don't build them with this patch. In the absence of them, Linux > > assigns its own unique IDs. The maintainers have chosen not to use > > counters from zero, but rather ACPI table offsets, which explains > > why the numbers are so much larger than with DT. > > > > 4) When there is no SMT (threads=1) the core IDs for ACPI boot guests > > match the logical CPU IDs, because these IDs must be equal to the > > MADT CPU UID (as no processor containers are present), and QEMU > > uses the logical CPU ID for these MADT IDs. > > > > Tested-by: Jiajie Li <lijiajie11(a)huawei.com> > > Signed-off-by: Andrew Jones <drjones(a)redhat.com> > > Signed-off-by: Ying Fang <fangying1(a)huawei.com> > > Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > > --- > > hw/arm/virt-acpi-build.c | 63 ++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 63 insertions(+) > > > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c > > index 2ad5dad1bf..03fd812d5a 100644 > > --- a/hw/arm/virt-acpi-build.c > > +++ b/hw/arm/virt-acpi-build.c > > @@ -436,6 +436,64 @@ build_srat(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > > vms->oem_table_id); > > } > > > > +/* PPTT */ > > +static void > > +build_pptt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) > > +{ > > + int pptt_start = table_data->len; > > + int uid = 0, cpus = 0, socket = 0; > > + MachineState *ms = MACHINE(vms); > > + unsigned int smp_cores = ms->smp.cores; > > + unsigned int smp_threads = ms->smp.threads; > > + > > + acpi_data_push(table_data, sizeof(AcpiTableHeader)); > > + > > + for (socket = 0; cpus < ms->possible_cpus->len; socket++) { > > + uint32_t socket_offset = table_data->len - pptt_start; > > + int core; > > + > > + build_processor_hierarchy_node( > > + table_data, 1, /* Physical package */ > > + 0, socket, /* No parent */ > > + NULL, 0); /* No private resources */ > > + > > + for (core = 0; core < smp_cores; core++) { > > + uint32_t core_offset = table_data->len - pptt_start; > > + int thread; > > + > > + if (smp_threads <= 1) { > > + build_processor_hierarchy_node( > > + table_data, > > + (1 << 1) | /* ACPI Processor ID valid */ > > + (1 << 3), /* ACPI 6.3 - Node is a Leaf */ > > + socket_offset, uid++, /* Parent is a Socket */ > > + NULL, 0); /* No private resources */ > > + } else { > > + build_processor_hierarchy_node( > > + table_data, 0, > > + socket_offset, core, /* Parent is a Socket */ > > + NULL, 0); /* No private resources */ > > + > > + for (thread = 0; thread < smp_threads; thread++) { > > + build_processor_hierarchy_node( > > + table_data, > > + (1 << 1) | /* ACPI Processor ID valid */ > > + (1 << 2) | /* ACPI 6.3 - Processor is a Thread */ > > + (1 << 3), /* ACPI 6.3 - Node is a Leaf */ > > + core_offset, uid++, /* Parent is a Core */ > > + NULL, 0); /* No private resources */ > > + } > > + } > > + } > > + cpus += smp_cores * smp_threads; > > + } > > + > > + build_header(linker, table_data, > > + (void *)(table_data->data + pptt_start), "PPTT", > > + table_data->len - pptt_start, 2, > > + vms->oem_id, vms->oem_table_id); > > +} > > + > > /* GTDT */ > > static void > > build_gtdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms) > > @@ -707,6 +765,11 @@ void virt_acpi_build(VirtMachineState *vms, > AcpiBuildTables *tables) > > acpi_add_table(table_offsets, tables_blob); > > build_madt(tables_blob, tables->linker, vms); > > > > + if (ms->smp.cpus > 1 && !vmc->no_cpu_topology) { > I'm not really sure why we need to care about "ms->smp.cpus > 1" here? > > IMO, just like MADT in which we create both ENABLED and DISABLED > gicc nodes no matter of number of ENABLED nodes is one or not, we > should create PPTT table for all the possible cpus and not care about > number of smp cpus, too. This will be more consistent with the ACPI > specification and the PPTT table will be used for ACPI cpu hotplug in > the future even with "smp.cpus == 1". A humble request: Let us not anticipate the changes of vcpu Hotplug here. Things are fluid with respect to the vcpu Hotplug right now and I think it will not be right to base PPTT Table changes in anticipation of something we are not sure of what it looks like. Any such decisions should be postponed and be made part of the actual vcpu Hotplug changes when(and if ever) they come for ARM64. This will also ensure proper review of such changes and useful in that particular context. Thanks > > Care of "smp.cpus > 1" in the DT cpu-map part makes sense to me, > because we are required to only add present cpu nodes to the DT and > Linux Doc says that a cpu-map is not needed for uniprocessor systems. > > Thanks, > Yanan > > + acpi_add_table(table_offsets, tables_blob); > > + build_pptt(tables_blob, tables->linker, vms); > > + } > > + > > acpi_add_table(table_offsets, tables_blob); > > build_gtdt(tables_blob, tables->linker, vms); > >

3 13

[PATCH] topology: use bin_attribute to avoid buff overflow
by Tian Tao 19 May '21

19 May '21

Use bin_attribute to display thread_siblings/core_cpus/core_siblings, die_cpus/package_cpus/book_siblings/drawer_siblings,avoiding NR_CPUS too big to cause buff overflow. This patch is based on the following discussion. https://www.spinics.net/lists/linux-doc/msg95921.html Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- drivers/base/topology.c | 54 +++++++++++++++++++++++++++++++------------------ 1 file changed, 34 insertions(+), 20 deletions(-) diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 4d254fc..be589b6b 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -21,11 +21,15 @@ static ssize_t name##_show(struct device *dev, \ return sysfs_emit(buf, "%d\n", topology_##name(dev->id)); \ } -#define define_siblings_show_map(name, mask) \ -static ssize_t name##_show(struct device *dev, \ - struct device_attribute *attr, char *buf) \ -{ \ - return cpumap_print_to_pagebuf(false, buf, topology_##mask(dev->id));\ +#define define_siblings_read(name, mask) \ +static ssize_t name##_read(struct file *file, struct kobject *kobj, \ + struct bin_attribute *attr, char *buf, \ + loff_t off, size_t count) \ +{ \ + struct device *dev = kobj_to_dev(kobj); \ + char temp[(NR_CPUS/32)*9] = {0}; \ + cpumap_print_to_pagebuf(false, temp, topology_##mask(dev->id)); \ + return memory_read_from_buffer(buf, count, &off, temp, (NR_CPUS/32)*9); \ } #define define_siblings_show_list(name, mask) \ @@ -37,7 +41,7 @@ static ssize_t name##_list_show(struct device *dev, \ } #define define_siblings_show_func(name, mask) \ - define_siblings_show_map(name, mask); \ + define_siblings_read(name, mask); \ define_siblings_show_list(name, mask) define_id_show_func(physical_package_id); @@ -50,30 +54,30 @@ define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); define_siblings_show_func(thread_siblings, sibling_cpumask); -static DEVICE_ATTR_RO(thread_siblings); +static BIN_ATTR_RO(thread_siblings, 0); static DEVICE_ATTR_RO(thread_siblings_list); define_siblings_show_func(core_cpus, sibling_cpumask); -static DEVICE_ATTR_RO(core_cpus); +static BIN_ATTR_RO(core_cpus, 0); static DEVICE_ATTR_RO(core_cpus_list); define_siblings_show_func(core_siblings, core_cpumask); -static DEVICE_ATTR_RO(core_siblings); +static BIN_ATTR_RO(core_siblings, 0); static DEVICE_ATTR_RO(core_siblings_list); define_siblings_show_func(die_cpus, die_cpumask); -static DEVICE_ATTR_RO(die_cpus); +static BIN_ATTR_RO(die_cpus, 0); static DEVICE_ATTR_RO(die_cpus_list); define_siblings_show_func(package_cpus, core_cpumask); -static DEVICE_ATTR_RO(package_cpus); +static BIN_ATTR_RO(package_cpus, 0); static DEVICE_ATTR_RO(package_cpus_list); #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); define_siblings_show_func(book_siblings, book_cpumask); -static DEVICE_ATTR_RO(book_siblings); +static BIN_ATTR_RO(book_siblings, 0); static DEVICE_ATTR_RO(book_siblings_list); #endif @@ -81,32 +85,41 @@ static DEVICE_ATTR_RO(book_siblings_list); define_id_show_func(drawer_id); static DEVICE_ATTR_RO(drawer_id); define_siblings_show_func(drawer_siblings, drawer_cpumask); -static DEVICE_ATTR_RO(drawer_siblings); +static BIN_ATTR_RO(drawer_siblings, 0); static DEVICE_ATTR_RO(drawer_siblings_list); #endif + +static struct bin_attribute *bin_attrs[] = { + &bin_attr_thread_siblings, + &bin_attr_core_cpus, + &bin_attr_core_siblings, + &bin_attr_die_cpus, + &bin_attr_package_cpus, +#ifdef CONFIG_SCHED_BOOK + &bin_attr_book_siblings, +#endif +#ifdef CONFIG_SCHED_DRAWER + &bin_attr_drawer_siblings, +#endif + NULL, +}; + static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, &dev_attr_die_id.attr, &dev_attr_core_id.attr, - &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, - &dev_attr_core_cpus.attr, &dev_attr_core_cpus_list.attr, - &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, - &dev_attr_die_cpus.attr, &dev_attr_die_cpus_list.attr, - &dev_attr_package_cpus.attr, &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, - &dev_attr_book_siblings.attr, &dev_attr_book_siblings_list.attr, #endif #ifdef CONFIG_SCHED_DRAWER &dev_attr_drawer_id.attr, - &dev_attr_drawer_siblings.attr, &dev_attr_drawer_siblings_list.attr, #endif NULL @@ -114,6 +127,7 @@ static struct attribute *default_attrs[] = { static const struct attribute_group topology_attr_group = { .attrs = default_attrs, + .bin_attrs = bin_attrs, .name = "topology" }; -- 2.7.4

1 0

Re: [RFC PATCH v3 4/9] hw/arm/virt: Initialize the present cpu members
by Salil Mehta 19 May '21

19 May '21

> From: wangyanan (Y) > Sent: Tuesday, May 18, 2021 5:43 AM > > Hi Salil, > > On 2021/5/18 4:48, Salil Mehta wrote: > >> From: Qemu-arm > [mailto:qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org] > >> On Behalf Of Yanan Wang > >> Sent: Sunday, May 16, 2021 11:29 AM > >> To: Peter Maydell <peter.maydell(a)linaro.org>; Andrew Jones > >> <drjones(a)redhat.com>; Michael S . Tsirkin <mst(a)redhat.com>; Igor Mammedov > >> <imammedo(a)redhat.com>; Shannon Zhao <shannon.zhaosl(a)gmail.com>; Alistair > >> Francis <alistair.francis(a)wdc.com>; David Gibson > >> <david(a)gibson.dropbear.id.au>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > >> Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; zhukeqian > >> <zhukeqian1(a)huawei.com>; yangyicong <yangyicong(a)huawei.com>; Zengtao (B) > >> <prime.zeng(a)hisilicon.com>; Wanghaibin (D) <wanghaibin.wang(a)huawei.com>; > >> yuzenghui <yuzenghui(a)huawei.com>; Paolo Bonzini <pbonzini(a)redhat.com>; > >> Philippe Mathieu-Daudé <philmd(a)redhat.com> > >> Subject: [RFC PATCH v3 4/9] hw/arm/virt: Initialize the present cpu members > >> > >> We create and initialize a cpuobj for each present cpu in > >> machvirt_init(). Now we also initialize the cpu member of > >> structure CPUArchId for each present cpu in the function. > > [...] > > > >> qdev_realize(DEVICE(cpuobj), NULL, &error_fatal); > >> + > >> + /* > >> + * As ARM cpu hotplug is not supported yet, we initialize > >> + * the present cpu members here. > >> + */ > >> + machine->possible_cpus->cpus[n].cpu = cpuobj; > > > > when vcpu Hotplug is not supported yet, what necessitates this change now? > > > The initialization will gives a way to determine whether a CPU is > present or not. > At least, for now it will be used when generating ACPI tables, e.g. > DSDT, MADT. > See patch 5 and 6. yes, but why do you require it now as part of the vcpu topology change? As-far-as-i-can-see, PPTT table changes(part of patch 5/9) do not require this change. Change in Patch 5/9 has also been done in anticipation of some future requirement(vcpu Hotplug?). Please correct me here if I am wrong? Thanks

2 2

Re: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in generation of MADT
by Salil Mehta 18 May '21

18 May '21

> From: wangyanan (Y) > Sent: Tuesday, May 18, 2021 6:03 AM > > Hi Salil, > > On 2021/5/18 1:07, Salil Mehta wrote: > >> From: Qemu-arm > [mailto:qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org] > >> On Behalf Of Yanan Wang > >> Sent: Sunday, May 16, 2021 11:29 AM > >> To: Peter Maydell <peter.maydell(a)linaro.org>; Andrew Jones > >> <drjones(a)redhat.com>; Michael S . Tsirkin <mst(a)redhat.com>; Igor Mammedov > >> <imammedo(a)redhat.com>; Shannon Zhao <shannon.zhaosl(a)gmail.com>; Alistair > >> Francis <alistair.francis(a)wdc.com>; David Gibson > >> <david(a)gibson.dropbear.id.au>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > >> Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; zhukeqian > >> <zhukeqian1(a)huawei.com>; yangyicong <yangyicong(a)huawei.com>; Zengtao (B) > >> <prime.zeng(a)hisilicon.com>; Wanghaibin (D) <wanghaibin.wang(a)huawei.com>; > >> yuzenghui <yuzenghui(a)huawei.com>; Paolo Bonzini <pbonzini(a)redhat.com>; > >> Philippe Mathieu-Daudé <philmd(a)redhat.com> > >> Subject: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in > >> generation of MADT > >> > >> When building ACPI tables regarding CPUs we should always build > >> them for the number of possible CPUs, not the number of present > >> CPUs. So we create gicc nodes in MADT for possible cpus and then > >> ensure only the present CPUs are marked ENABLED. Furthermore, it > >> also needed if we are going to support CPU hotplug in the future. > > Hi Yanan, > > Yes, these changes are part of the QEMU patch-set I floated last year. > > > > Link: https://www.mail-archive.com/qemu-devel@nongnu.org/msg712018.html > Yes, I noticed this. Thanks! > > > > Perhaps I am missing something, but how this patch is related to the vcpu > > topology support? > No related actually. But this patch together with patch 5 aim to provide > complete information (all cpus including enabled and the others) to guest, > which will be more consistent with requirement in ACPI spec. Well, if it is not related to the cpu topology support then this and other similar patches included with the same line of thought should not be part of this patch-set. I am already working with ARM folks in this regard. Thanks > > We don't consider cpu hotplug at all in this patch, but it indeed pave way > for cpu hotplug in the future. > > Thanks, > Yanan > > Thanks > > > >> Co-developed-by: Andrew Jones <drjones(a)redhat.com> > >> Signed-off-by: Andrew Jones <drjones(a)redhat.com> > >> Co-developed-by: Ying Fang <fangying1(a)huawei.com> > >> Signed-off-by: Ying Fang <fangying1(a)huawei.com> > >> Co-developed-by: Yanan Wang <wangyanan55(a)huawei.com> > >> Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > >> --- > >> hw/arm/virt-acpi-build.c | 29 +++++++++++++++++++++++++---- > >> 1 file changed, 25 insertions(+), 4 deletions(-) > >> > >> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c > >> index a2d8e87616..4d64aeb865 100644 > >> --- a/hw/arm/virt-acpi-build.c > >> +++ b/hw/arm/virt-acpi-build.c > >> @@ -481,6 +481,9 @@ build_madt(GArray *table_data, BIOSLinker *linker, > >> VirtMachineState *vms) > >> const int *irqmap = vms->irqmap; > >> AcpiMadtGenericDistributor *gicd; > >> AcpiMadtGenericMsiFrame *gic_msi; > >> + MachineClass *mc = MACHINE_GET_CLASS(vms); > >> + const CPUArchIdList *possible_cpus = > >> mc->possible_cpu_arch_ids(MACHINE(vms)); > >> + bool pmu; > >> int i; > >> > >> acpi_data_push(table_data, sizeof(AcpiMultipleApicTable)); > >> @@ -491,11 +494,21 @@ build_madt(GArray *table_data, BIOSLinker *linker, > >> VirtMachineState *vms) > >> gicd->base_address = cpu_to_le64(memmap[VIRT_GIC_DIST].base); > >> gicd->version = vms->gic_version; > >> > >> - for (i = 0; i < MACHINE(vms)->smp.cpus; i++) { > >> + for (i = 0; i < possible_cpus->len; i++) { > >> AcpiMadtGenericCpuInterface *gicc = acpi_data_push(table_data, > >> sizeof(*gicc)); > >> ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(i)); > >> > >> + /* > >> + * PMU should have been either implemented for all CPUs or not, > >> + * so we only get information from the first CPU, which could > >> + * represent the others. > >> + */ > >> + if (i == 0) { > >> + pmu = arm_feature(&armcpu->env, ARM_FEATURE_PMU); > >> + } > >> + assert(!armcpu || arm_feature(&armcpu->env, ARM_FEATURE_PMU) == > pmu); > >> + > >> gicc->type = ACPI_APIC_GENERIC_CPU_INTERFACE; > >> gicc->length = sizeof(*gicc); > >> if (vms->gic_version == 2) { > >> @@ -504,11 +517,19 @@ build_madt(GArray *table_data, BIOSLinker *linker, > >> VirtMachineState *vms) > >> gicc->gicv_base_address = > >> cpu_to_le64(memmap[VIRT_GIC_VCPU].base); > >> } > >> gicc->cpu_interface_number = cpu_to_le32(i); > >> - gicc->arm_mpidr = cpu_to_le64(armcpu->mp_affinity); > >> + gicc->arm_mpidr = cpu_to_le64(possible_cpus->cpus[i].arch_id); > >> gicc->uid = cpu_to_le32(i); > >> - gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED); > >> > >> - if (arm_feature(&armcpu->env, ARM_FEATURE_PMU)) { > >> + /* > >> + * ACPI spec says that LAPIC entry for non present CPU may be > >> + * omitted from MADT or it must be marked as disabled. Here we > >> + * choose to also keep the disabled ones in MADT. > >> + */ > >> + if (possible_cpus->cpus[i].cpu != NULL) { > >> + gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED); > >> + } > >> + > >> + if (pmu) { > >> gicc->performance_interrupt = > cpu_to_le32(PPI(VIRTUAL_PMU_IRQ)); > >> } > >> if (vms->virt) { > >> -- > >> 2.19.1 > >> > > .

2 1

Re: [PATCH v3] iommu/iova: put free_iova_mem() outside of spinlock iova_rbtree_lock
by Joerg Roedel 18 May '21

18 May '21

On Mon, Apr 19, 2021 at 03:13:35PM +0800, chenxiang wrote: > From: Xiang Chen <chenxiang66(a)hisilicon.com> > > It is not necessary to put free_iova_mem() inside of spinlock/unlock > iova_rbtree_lock which only leads to more completion for the spinlock. > It has a small promote on the performance after the change. And also > rename private_free_iova() as remove_iova() because the function will not > free iova after that change. > > Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> > --- > drivers/iommu/iova.c | 18 +++++++++++------- > 1 file changed, 11 insertions(+), 7 deletions(-) Looks good to me, but I'll wait for Robins opinion before applying.

3 3

Re: [RFC PATCH v3 4/4] hw/arm/virt: Parse -smp cluster parameter in virt_smp_parse
by Salil Mehta 18 May '21

18 May '21

> From: wangyanan (Y) > > Hi Salil, > > On 2021/5/17 23:17, Salil Mehta wrote: > >> From: Qemu-devel > >> [mailto:qemu-devel-bounces+salil.mehta=huawei.com@nongnu.org] On Behalf Of > >> Yanan Wang > >> Sent: Sunday, May 16, 2021 11:32 AM > >> To: Peter Maydell <peter.maydell(a)linaro.org>; Paolo Bonzini > >> <pbonzini(a)redhat.com>; Andrew Jones <drjones(a)redhat.com>; Michael S . Tsirkin > >> <mst(a)redhat.com>; Igor Mammedov <imammedo(a)redhat.com>; Shannon Zhao > >> <shannon.zhaosl(a)gmail.com>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > >> Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; Philippe > >> Mathieu-Daudé <philmd(a)redhat.com>; wangyanan (Y) <wangyanan55(a)huawei.com>; > >> Zengtao (B) <prime.zeng(a)hisilicon.com>; Wanghaibin (D) > >> <wanghaibin.wang(a)huawei.com>; yuzenghui <yuzenghui(a)huawei.com>; yangyicong > >> <yangyicong(a)huawei.com>; zhukeqian <zhukeqian1(a)huawei.com> > >> Subject: [RFC PATCH v3 4/4] hw/arm/virt: Parse -smp cluster parameter in > >> virt_smp_parse > >> > >> There is a separate function virt_smp_parse() in hw/virt/arm.c used > >> to parse cpu topology for the ARM machines. So add parsing of -smp > >> cluster parameter in it, then total number of logical cpus will be > >> calculated like: max_cpus = sockets * clusters * cores * threads. > >> > >> Note, we will assume multi-cluster in one socket is not supported > >> and default the value of clusters to 1, if it's not explicitly > >> specified in -smp cmdline. > >> > >> Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > >> --- > >> hw/arm/virt.c | 32 ++++++++++++++++++-------------- > >> 1 file changed, 18 insertions(+), 14 deletions(-) > >> > >> diff --git a/hw/arm/virt.c b/hw/arm/virt.c > >> index 7de822e491..678d5ef36c 100644 > >> --- a/hw/arm/virt.c > >> +++ b/hw/arm/virt.c > >> @@ -2642,8 +2642,8 @@ static int virt_kvm_type(MachineState *ms, const char > >> *type_str) > >> * with the -smp cmdlines when parsing them. > >> * > >> * We require that at least one of cpus or maxcpus must be provided. > >> - * Threads will default to 1 if not provided. Sockets and cores must > >> - * be either both provided or both not. > >> + * Clusters and threads will default to 1 if they are not provided. > >> + * Sockets and cores must be either both provided or both not. > >> * > >> * Note, if neither sockets nor cores are specified, we will calculate > >> * all the missing values just like smp_parse() does, but will disable > >> @@ -2652,15 +2652,18 @@ static int virt_kvm_type(MachineState *ms, const char > >> *type_str) > >> static void virt_smp_parse(MachineState *ms, QemuOpts *opts) > >> { > >> VirtMachineClass *vmc = VIRT_MACHINE_GET_CLASS(ms); > >> + VirtMachineState *vms = VIRT_MACHINE(ms); > >> > >> if (opts) { > >> unsigned cpus = qemu_opt_get_number(opts, "cpus", 0); > >> unsigned maxcpus = qemu_opt_get_number(opts, "maxcpus", 0); > >> unsigned sockets = qemu_opt_get_number(opts, "sockets", 0); > >> + unsigned clusters = qemu_opt_get_number(opts, "clusters", 0); > >> unsigned cores = qemu_opt_get_number(opts, "cores", 0); > >> unsigned threads = qemu_opt_get_number(opts, "threads", 0); > >> > >> - /* Default threads to 1 if not provided */ > >> + /* Default clusters and threads to 1 if not provided */ > >> + clusters = clusters > 0 ? clusters : 1; > >> threads = threads > 0 ? threads : 1; > >> > >> if (cpus == 0 && maxcpus == 0) { > >> @@ -2676,13 +2679,13 @@ static void virt_smp_parse(MachineState *ms, QemuOpts > >> *opts) > >> cores = 1; > >> if (cpus == 0) { > >> sockets = 1; > >> - cpus = sockets * cores * threads; > >> + cpus = sockets * clusters * cores * threads; > >> } else { > >> maxcpus = maxcpus > 0 ? maxcpus : cpus; > >> - sockets = maxcpus / (cores * threads); > >> + sockets = maxcpus / (clusters * cores * threads); > >> } > >> } else if (sockets > 0 && cores > 0) { > >> - cpus = cpus > 0 ? cpus : sockets * cores * threads; > >> + cpus = cpus > 0 ? cpus : sockets * clusters * cores * threads; > >> maxcpus = maxcpus > 0 ? maxcpus : cpus; > >> } else { > >> error_report("sockets and cores must be both provided " > >> @@ -2695,25 +2698,26 @@ static void virt_smp_parse(MachineState *ms, QemuOpts > >> *opts) > >> exit(1); > >> } > >> > >> - if (sockets * cores * threads < cpus) { > >> + if (sockets * clusters * cores * threads < cpus) { > >> error_report("cpu topology: " > >> - "sockets (%u) * cores (%u) * threads (%u) < " > >> - "smp_cpus (%u)", > >> - sockets, cores, threads, cpus); > >> + "sockets (%u) * clusters (%u) * cores (%u) * " > >> + "threads (%u) < smp_cpus (%u)", > >> + sockets, clusters, cores, threads, cpus); > >> exit(1); > >> } > >> > >> - if (sockets * cores * threads != maxcpus) { > >> + if (sockets * clusters * cores * threads != maxcpus) { > >> error_report("cpu topology: " > >> - "sockets (%u) * cores (%u) * threads (%u) " > >> - "!= maxcpus (%u)", > >> - sockets, cores, threads, maxcpus); > >> + "sockets (%u) * clusters (%u) * cores (%u) * " > >> + "threads (%u) != maxcpus (%u)", > >> + sockets, clusters, cores, threads, maxcpus); > >> exit(1); > >> } > >> > >> ms->smp.cpus = cpus; > >> ms->smp.max_cpus = maxcpus; > >> ms->smp.sockets = sockets; > >> + vms->smp_clusters = clusters; > > > > This variable naming *smp_clusters* looks out-of-sorts. I thought a similar > > variable *smp_cpus* was destined to be removed for the reason given in below > > link - a patch by Andrew Jones? > > > > Link: https://lists.gnu.org/archive/html/qemu-arm/2020-12/msg00418.html > > > > Am I missing anything here? > The smp_clusters is added in VirtMachineState and nowhere else because > it's currently only used for ARM. But I think maybe I should also move it to > CpuTopology structure like [1] is doing to move dies to CpuTopology. yes, that’s the idea. It is always good to have right place holders so that the code comprehension/usage(in this case) becomes easy and obvious. > > Move clusters to CpuTopology won't affect other architectures that don't > support it yet, and will also make it easy if they want to in the future. > > [1] From Paolo: > https://patchwork.kernel.org/project/qemu-devel/patch/20210513162901.131023 > 9-10-pbonzini(a)redhat.com/ sure. > > Thanks, > Yanan > > Salil. > > > >> ms->smp.cores = cores; > >> ms->smp.threads = threads; > >> }

1 0

Re: [PATCH net v8 1/3] net: sched: fix packet stuck problem for lockless qdisc
by Cong Wang 18 May '21

18 May '21

On Fri, May 14, 2021 at 7:25 PM Yunsheng Lin <linyunsheng(a)huawei.com> wrote: > > On 2021/5/15 8:17, Jakub Kicinski wrote: > > On Fri, 14 May 2021 16:57:29 -0700 Cong Wang wrote: > >> On Fri, May 14, 2021 at 4:39 PM Jakub Kicinski <kuba(a)kernel.org> wrote: > >>> > >>> On Fri, 14 May 2021 16:36:16 -0700 Cong Wang wrote: > >> [...] > >>>> > >>>> We have test_and_clear_bit() which is atomic, test_bit()+clear_bit() > >>>> is not. > >>> > >>> It doesn't have to be atomic, right? I asked to split the test because > >>> test_and_clear is a locked op on x86, test by itself is not. > >> > >> It depends on whether you expect the code under the true condition > >> to run once or multiple times, something like: > >> > >> if (test_bit()) { > >> clear_bit(); > >> // this code may run multiple times > >> } > >> > >> With the atomic test_and_clear_bit(), it only runs once: > >> > >> if (test_and_clear_bit()) { > >> // this code runs once > >> } > > I am not sure if the above really matter when the test and clear > does not need to be atomic. > > In order for the above to happens, the MISSED has to set between > test and clear, right? Nope, see the following: // MISSED bit is already set CPU0 CPU1 if (test_bit(MISSED) ( //true if (test_bit(MISSED)) { // also true clear_bit(MISSED); do_something(); clear_bit(MISSED); do_something(); } } Now do_something() is called twice instead of once. This may or may not be a problem, hence I asked this question. > > >> > >> This is why __netif_schedule() uses test_and_set_bit() instead of > >> test_bit()+set_bit(). > > I think test_and_set_bit() is needed in __netif_schedule() mainly > because STATE_SCHED is also used to indicate if the qdisc is in > sd->output_queue, so it has to be atomic. If you replace the "do_something()" above with __netif_reschedule(), this is exactly my point. An entry can not be inserted twice into a list, hence it should never be called twice like above. Thanks.

1 0

Re: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in generation of MADT
by Salil Mehta 18 May '21

18 May '21

> From: Qemu-arm [mailto:qemu-arm-bounces+salil.mehta=huawei.com@nongnu.org] > On Behalf Of Yanan Wang > Sent: Sunday, May 16, 2021 11:29 AM > To: Peter Maydell <peter.maydell(a)linaro.org>; Andrew Jones > <drjones(a)redhat.com>; Michael S . Tsirkin <mst(a)redhat.com>; Igor Mammedov > <imammedo(a)redhat.com>; Shannon Zhao <shannon.zhaosl(a)gmail.com>; Alistair > Francis <alistair.francis(a)wdc.com>; David Gibson > <david(a)gibson.dropbear.id.au>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; zhukeqian > <zhukeqian1(a)huawei.com>; yangyicong <yangyicong(a)huawei.com>; Zengtao (B) > <prime.zeng(a)hisilicon.com>; Wanghaibin (D) <wanghaibin.wang(a)huawei.com>; > yuzenghui <yuzenghui(a)huawei.com>; Paolo Bonzini <pbonzini(a)redhat.com>; > Philippe Mathieu-Daudé <philmd(a)redhat.com> > Subject: [RFC PATCH v3 6/9] hw/arm/virt-acpi-build: Use possible cpus in > generation of MADT > > When building ACPI tables regarding CPUs we should always build > them for the number of possible CPUs, not the number of present > CPUs. So we create gicc nodes in MADT for possible cpus and then > ensure only the present CPUs are marked ENABLED. Furthermore, it > also needed if we are going to support CPU hotplug in the future. Hi Yanan, Yes, these changes are part of the QEMU patch-set I floated last year. Link: https://www.mail-archive.com/qemu-devel@nongnu.org/msg712018.html Perhaps I am missing something, but how this patch is related to the vcpu topology support? Thanks > > Co-developed-by: Andrew Jones <drjones(a)redhat.com> > Signed-off-by: Andrew Jones <drjones(a)redhat.com> > Co-developed-by: Ying Fang <fangying1(a)huawei.com> > Signed-off-by: Ying Fang <fangying1(a)huawei.com> > Co-developed-by: Yanan Wang <wangyanan55(a)huawei.com> > Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > --- > hw/arm/virt-acpi-build.c | 29 +++++++++++++++++++++++++---- > 1 file changed, 25 insertions(+), 4 deletions(-) > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c > index a2d8e87616..4d64aeb865 100644 > --- a/hw/arm/virt-acpi-build.c > +++ b/hw/arm/virt-acpi-build.c > @@ -481,6 +481,9 @@ build_madt(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > const int *irqmap = vms->irqmap; > AcpiMadtGenericDistributor *gicd; > AcpiMadtGenericMsiFrame *gic_msi; > + MachineClass *mc = MACHINE_GET_CLASS(vms); > + const CPUArchIdList *possible_cpus = > mc->possible_cpu_arch_ids(MACHINE(vms)); > + bool pmu; > int i; > > acpi_data_push(table_data, sizeof(AcpiMultipleApicTable)); > @@ -491,11 +494,21 @@ build_madt(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > gicd->base_address = cpu_to_le64(memmap[VIRT_GIC_DIST].base); > gicd->version = vms->gic_version; > > - for (i = 0; i < MACHINE(vms)->smp.cpus; i++) { > + for (i = 0; i < possible_cpus->len; i++) { > AcpiMadtGenericCpuInterface *gicc = acpi_data_push(table_data, > sizeof(*gicc)); > ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(i)); > > + /* > + * PMU should have been either implemented for all CPUs or not, > + * so we only get information from the first CPU, which could > + * represent the others. > + */ > + if (i == 0) { > + pmu = arm_feature(&armcpu->env, ARM_FEATURE_PMU); > + } > + assert(!armcpu || arm_feature(&armcpu->env, ARM_FEATURE_PMU) == pmu); > + > gicc->type = ACPI_APIC_GENERIC_CPU_INTERFACE; > gicc->length = sizeof(*gicc); > if (vms->gic_version == 2) { > @@ -504,11 +517,19 @@ build_madt(GArray *table_data, BIOSLinker *linker, > VirtMachineState *vms) > gicc->gicv_base_address = > cpu_to_le64(memmap[VIRT_GIC_VCPU].base); > } > gicc->cpu_interface_number = cpu_to_le32(i); > - gicc->arm_mpidr = cpu_to_le64(armcpu->mp_affinity); > + gicc->arm_mpidr = cpu_to_le64(possible_cpus->cpus[i].arch_id); > gicc->uid = cpu_to_le32(i); > - gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED); > > - if (arm_feature(&armcpu->env, ARM_FEATURE_PMU)) { > + /* > + * ACPI spec says that LAPIC entry for non present CPU may be > + * omitted from MADT or it must be marked as disabled. Here we > + * choose to also keep the disabled ones in MADT. > + */ > + if (possible_cpus->cpus[i].cpu != NULL) { > + gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED); > + } > + > + if (pmu) { > gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ)); > } > if (vms->virt) { > -- > 2.19.1 >

1 0

Re: [RFC PATCH v3 4/4] hw/arm/virt: Parse -smp cluster parameter in virt_smp_parse
by Salil Mehta 17 May '21

17 May '21

> From: Qemu-devel > [mailto:qemu-devel-bounces+salil.mehta=huawei.com@nongnu.org] On Behalf Of > Yanan Wang > Sent: Sunday, May 16, 2021 11:32 AM > To: Peter Maydell <peter.maydell(a)linaro.org>; Paolo Bonzini > <pbonzini(a)redhat.com>; Andrew Jones <drjones(a)redhat.com>; Michael S . Tsirkin > <mst(a)redhat.com>; Igor Mammedov <imammedo(a)redhat.com>; Shannon Zhao > <shannon.zhaosl(a)gmail.com>; qemu-devel(a)nongnu.org; qemu-arm(a)nongnu.org > Cc: Song Bao Hua (Barry Song) <song.bao.hua(a)hisilicon.com>; Philippe > Mathieu-Daudé <philmd(a)redhat.com>; wangyanan (Y) <wangyanan55(a)huawei.com>; > Zengtao (B) <prime.zeng(a)hisilicon.com>; Wanghaibin (D) > <wanghaibin.wang(a)huawei.com>; yuzenghui <yuzenghui(a)huawei.com>; yangyicong > <yangyicong(a)huawei.com>; zhukeqian <zhukeqian1(a)huawei.com> > Subject: [RFC PATCH v3 4/4] hw/arm/virt: Parse -smp cluster parameter in > virt_smp_parse > > There is a separate function virt_smp_parse() in hw/virt/arm.c used > to parse cpu topology for the ARM machines. So add parsing of -smp > cluster parameter in it, then total number of logical cpus will be > calculated like: max_cpus = sockets * clusters * cores * threads. > > Note, we will assume multi-cluster in one socket is not supported > and default the value of clusters to 1, if it's not explicitly > specified in -smp cmdline. > > Signed-off-by: Yanan Wang <wangyanan55(a)huawei.com> > --- > hw/arm/virt.c | 32 ++++++++++++++++++-------------- > 1 file changed, 18 insertions(+), 14 deletions(-) > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > index 7de822e491..678d5ef36c 100644 > --- a/hw/arm/virt.c > +++ b/hw/arm/virt.c > @@ -2642,8 +2642,8 @@ static int virt_kvm_type(MachineState *ms, const char > *type_str) > * with the -smp cmdlines when parsing them. > * > * We require that at least one of cpus or maxcpus must be provided. > - * Threads will default to 1 if not provided. Sockets and cores must > - * be either both provided or both not. > + * Clusters and threads will default to 1 if they are not provided. > + * Sockets and cores must be either both provided or both not. > * > * Note, if neither sockets nor cores are specified, we will calculate > * all the missing values just like smp_parse() does, but will disable > @@ -2652,15 +2652,18 @@ static int virt_kvm_type(MachineState *ms, const char > *type_str) > static void virt_smp_parse(MachineState *ms, QemuOpts *opts) > { > VirtMachineClass *vmc = VIRT_MACHINE_GET_CLASS(ms); > + VirtMachineState *vms = VIRT_MACHINE(ms); > > if (opts) { > unsigned cpus = qemu_opt_get_number(opts, "cpus", 0); > unsigned maxcpus = qemu_opt_get_number(opts, "maxcpus", 0); > unsigned sockets = qemu_opt_get_number(opts, "sockets", 0); > + unsigned clusters = qemu_opt_get_number(opts, "clusters", 0); > unsigned cores = qemu_opt_get_number(opts, "cores", 0); > unsigned threads = qemu_opt_get_number(opts, "threads", 0); > > - /* Default threads to 1 if not provided */ > + /* Default clusters and threads to 1 if not provided */ > + clusters = clusters > 0 ? clusters : 1; > threads = threads > 0 ? threads : 1; > > if (cpus == 0 && maxcpus == 0) { > @@ -2676,13 +2679,13 @@ static void virt_smp_parse(MachineState *ms, QemuOpts > *opts) > cores = 1; > if (cpus == 0) { > sockets = 1; > - cpus = sockets * cores * threads; > + cpus = sockets * clusters * cores * threads; > } else { > maxcpus = maxcpus > 0 ? maxcpus : cpus; > - sockets = maxcpus / (cores * threads); > + sockets = maxcpus / (clusters * cores * threads); > } > } else if (sockets > 0 && cores > 0) { > - cpus = cpus > 0 ? cpus : sockets * cores * threads; > + cpus = cpus > 0 ? cpus : sockets * clusters * cores * threads; > maxcpus = maxcpus > 0 ? maxcpus : cpus; > } else { > error_report("sockets and cores must be both provided " > @@ -2695,25 +2698,26 @@ static void virt_smp_parse(MachineState *ms, QemuOpts > *opts) > exit(1); > } > > - if (sockets * cores * threads < cpus) { > + if (sockets * clusters * cores * threads < cpus) { > error_report("cpu topology: " > - "sockets (%u) * cores (%u) * threads (%u) < " > - "smp_cpus (%u)", > - sockets, cores, threads, cpus); > + "sockets (%u) * clusters (%u) * cores (%u) * " > + "threads (%u) < smp_cpus (%u)", > + sockets, clusters, cores, threads, cpus); > exit(1); > } > > - if (sockets * cores * threads != maxcpus) { > + if (sockets * clusters * cores * threads != maxcpus) { > error_report("cpu topology: " > - "sockets (%u) * cores (%u) * threads (%u) " > - "!= maxcpus (%u)", > - sockets, cores, threads, maxcpus); > + "sockets (%u) * clusters (%u) * cores (%u) * " > + "threads (%u) != maxcpus (%u)", > + sockets, clusters, cores, threads, maxcpus); > exit(1); > } > > ms->smp.cpus = cpus; > ms->smp.max_cpus = maxcpus; > ms->smp.sockets = sockets; > + vms->smp_clusters = clusters; This variable naming *smp_clusters* looks out-of-sorts. I thought a similar variable *smp_cpus* was destined to be removed for the reason given in below link - a patch by Andrew Jones? Link: https://lists.gnu.org/archive/html/qemu-arm/2020-12/msg00418.html Am I missing anything here? Salil. > ms->smp.cores = cores; > ms->smp.threads = threads; > }

1 0

[PATCH 8/9] tty: hvc_console: Remove the repeated words 'no' and 'from'
by Xiaofei Tan 17 May '21

17 May '21

Remove the repeated words 'no' and 'from', reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index f31efeb..b6720b0 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -293,7 +293,7 @@ int hvc_instantiate(uint32_t vtermno, int index, const struct hv_ops *ops) if (vtermnos[index] != -1) return -1; - /* make sure no no tty has been registered in this index */ + /* make sure no tty has been registered in this index */ hp = hvc_get_by_index(index); if (hp) { tty_port_put(&hp->port); @@ -622,7 +622,7 @@ static u32 timeout = MIN_TIMEOUT; /* * Maximum number of bytes to get from the console driver if hvc_poll is * called from driver (and can't sleep). Any more than this and we break - * and start polling with khvcd. This value was derived from from an OpenBMC + * and start polling with khvcd. This value was derived from an OpenBMC * console with the OPAL driver that results in about 0.25ms interrupts off * latency. */ -- 2.8.1

1 0

[PATCH 7/9] tty: hvc_console: Add a blank line after declarations
by Xiaofei Tan 17 May '21

17 May '21

Add a blank line after declarations, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index a61cdf0..f31efeb 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -922,6 +922,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data, /* We wait until a driver actually comes along */ if (atomic_inc_not_zero(&hvc_needs_init)) { int err = hvc_init(); + if (err) return ERR_PTR(err); } -- 2.8.1

1 0

[PATCH 5/9] tty: hvc_console: Delete spaces prohibited around open parenthesis '(' and ')'
by Xiaofei Tan 17 May '21

17 May '21

Delete spaces prohibited after that open parenthesis '(' and before that close parenthesis ')', reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index 2e5c133..39018e5 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -689,7 +689,7 @@ static int __hvc_poll(struct hvc_struct *hp, bool may_sleep) spin_unlock_irqrestore(&hp->lock, flags); tty_hangup(tty); spin_lock_irqsave(&hp->lock, flags); - } else if ( n == -EAGAIN ) { + } else if (n == -EAGAIN) { /* * Some back-ends can only ensure a certain min * num of bytes read, which may be > 'count'. -- 2.8.1

1 0

[PATCH 3/9] tty: hvc_console: Remove trailing whitespace
by Xiaofei Tan 17 May '21

17 May '21

Remove trailing whitespace, reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index ddf07ff..13f63d5 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -204,7 +204,7 @@ static struct tty_driver *hvc_console_device(struct console *c, int *index) } static int hvc_console_setup(struct console *co, char *options) -{ +{ if (co->index < 0 || co->index >= MAX_NR_HVC_CONSOLES) return -ENODEV; -- 2.8.1

1 0

[PATCH 2/9] tty: hvc_console: Fix "foo * bar" should be "foo *bar"
by Xiaofei Tan 17 May '21

17 May '21

Fix "foo * bar" should be "foo *bar", reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index a1eca9d..ddf07ff 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -344,7 +344,7 @@ static int hvc_install(struct tty_driver *driver, struct tty_struct *tty) * The TTY interface won't be used until after the vio layer has exposed the vty * adapter to the kernel. */ -static int hvc_open(struct tty_struct *tty, struct file * filp) +static int hvc_open(struct tty_struct *tty, struct file *filp) { struct hvc_struct *hp = tty->driver_data; unsigned long flags; @@ -386,7 +386,7 @@ static int hvc_open(struct tty_struct *tty, struct file * filp) return rc; } -static void hvc_close(struct tty_struct *tty, struct file * filp) +static void hvc_close(struct tty_struct *tty, struct file *filp) { struct hvc_struct *hp = tty->driver_data; unsigned long flags; -- 2.8.1

1 0

[PATCH 1/9] tty: hvc_console: Fix spaces required around that '='
by Xiaofei Tan 17 May '21

17 May '21

Fix spaces required around that '=', reported by checkpatch.pl. Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- drivers/tty/hvc/hvc_console.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index d0f0253..a1eca9d 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -944,7 +944,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data, * find index to use: * see if this vterm id matches one registered for console. */ - for (i=0; i < MAX_NR_HVC_CONSOLES; i++) + for (i = 0; i < MAX_NR_HVC_CONSOLES; i++) if (vtermnos[i] == hp->vtermno && cons_ops[i] == hp->ops) break; -- 2.8.1

1 0

Re: [PATCH net v8 1/3] net: sched: fix packet stuck problem for lockless qdisc
by Cong Wang 15 May '21

15 May '21

On Thu, May 13, 2021 at 7:27 PM Yunsheng Lin <linyunsheng(a)huawei.com> wrote: > struct qdisc_size_table { > @@ -159,8 +160,33 @@ static inline bool qdisc_is_empty(const struct Qdisc *qdisc) > static inline bool qdisc_run_begin(struct Qdisc *qdisc) > { > if (qdisc->flags & TCQ_F_NOLOCK) { > + if (spin_trylock(&qdisc->seqlock)) > + goto nolock_empty; > + > + /* If the MISSED flag is set, it means other thread has > + * set the MISSED flag before second spin_trylock(), so > + * we can return false here to avoid multi cpus doing > + * the set_bit() and second spin_trylock() concurrently. > + */ > + if (test_bit(__QDISC_STATE_MISSED, &qdisc->state)) > + return false; > + > + /* Set the MISSED flag before the second spin_trylock(), > + * if the second spin_trylock() return false, it means > + * other cpu holding the lock will do dequeuing for us > + * or it will see the MISSED flag set after releasing > + * lock and reschedule the net_tx_action() to do the > + * dequeuing. > + */ > + set_bit(__QDISC_STATE_MISSED, &qdisc->state); > + > + /* Retry again in case other CPU may not see the new flag > + * after it releases the lock at the end of qdisc_run_end(). > + */ > if (!spin_trylock(&qdisc->seqlock)) > return false; > + > +nolock_empty: > WRITE_ONCE(qdisc->empty, false); > } else if (qdisc_is_running(qdisc)) { > return false; > @@ -176,8 +202,15 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc) > static inline void qdisc_run_end(struct Qdisc *qdisc) > { > write_seqcount_end(&qdisc->running); > - if (qdisc->flags & TCQ_F_NOLOCK) > + if (qdisc->flags & TCQ_F_NOLOCK) { > spin_unlock(&qdisc->seqlock); > + > + if (unlikely(test_bit(__QDISC_STATE_MISSED, > + &qdisc->state))) { > + clear_bit(__QDISC_STATE_MISSED, &qdisc->state); We have test_and_clear_bit() which is atomic, test_bit()+clear_bit() is not. > + __netif_schedule(qdisc); > + } > + } > } > > static inline bool qdisc_may_bulk(const struct Qdisc *qdisc) > diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c > index 44991ea..795d986 100644 > --- a/net/sched/sch_generic.c > +++ b/net/sched/sch_generic.c > @@ -640,8 +640,10 @@ static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc) > { > struct pfifo_fast_priv *priv = qdisc_priv(qdisc); > struct sk_buff *skb = NULL; > + bool need_retry = true; > int band; > > +retry: > for (band = 0; band < PFIFO_FAST_BANDS && !skb; band++) { > struct skb_array *q = band2list(priv, band); > > @@ -652,6 +654,23 @@ static struct sk_buff *pfifo_fast_dequeue(struct Qdisc *qdisc) > } > if (likely(skb)) { > qdisc_update_stats_at_dequeue(qdisc, skb); > + } else if (need_retry && > + test_bit(__QDISC_STATE_MISSED, &qdisc->state)) { > + /* Delay clearing the STATE_MISSED here to reduce > + * the overhead of the second spin_trylock() in > + * qdisc_run_begin() and __netif_schedule() calling > + * in qdisc_run_end(). > + */ > + clear_bit(__QDISC_STATE_MISSED, &qdisc->state); Ditto. > + > + /* Make sure dequeuing happens after clearing > + * STATE_MISSED. > + */ > + smp_mb__after_atomic(); > + > + need_retry = false; > + > + goto retry; Two concurrent pfifo_fast_dequeue() would possibly retry it at the same time when they test __QDISC_STATE_MISSED at the same time and get true. Is this a problem? Also, any reason why you want pfifo_fast to handle a generic Qdisc flag? IOW, why not handle this logic in, for example, qdisc_restart()? Thanks.

2 3

Re: [PATCH net v8 0/3] fix packet stuck problem for lockless qdisc
by patchwork-bot+netdevbpf＠kernel.org 15 May '21

15 May '21

Hello: This series was applied to netdev/net.git (refs/heads/master): On Fri, 14 May 2021 11:16:58 +0800 you wrote: > This patchset fixes the packet stuck problem mentioned in [1]. > > Patch 1: Add STATE_MISSED flag to fix packet stuck problem. > Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED > flag is added in patch 1. > Patch 3: Fix the significantly higher CPU consumption problem when > multiple threads are competing on a saturated outgoing > device. > > [...] Here is the summary with links: - [net,v8,1/3] net: sched: fix packet stuck problem for lockless qdisc https://git.kernel.org/netdev/net/c/a90c57f2cedd - [net,v8,2/3] net: sched: fix tx action rescheduling issue during deactivation https://git.kernel.org/netdev/net/c/102b55ee92f9 - [net,v8,3/3] net: sched: fix tx action reschedule issue with stopped queue https://git.kernel.org/netdev/net/c/dcad9ee9e066 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

1 0

Re: [PATCH net v8 0/3] fix packet stuck problem for lockless qdisc
by Yunsheng Lin 14 May '21

14 May '21

On 2021/5/14 10:26, Yunsheng Lin wrote: > This patchset fixes the packet stuck problem mentioned in [1]. > > Patch 1: Add STATE_MISSED flag to fix packet stuck problem. > Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED > flag is added in patch 1. > Patch 3: Fix the significantly higher CPU consumption problem when > multiple threads are competing on a saturated outgoing > device. > > V8: Change function name in patch 3 as suggested by Jakub, adjust > commit log in patch 2, and add Acked-by from Jakub. Please ignore this patchset, there is some typo in patch 3. > V7: Fix netif_tx_wake_queue() data race noted by Jakub. > V6: Some performance optimization in patch 1 suggested by Jakub > and drop NET_XMIT_DROP checking in patch 3. > V5: add patch 3 to fix the problem reported by Michal Kubecek. > V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2. > > [1]. https://lkml.org/lkml/2019/10/9/42 > > Yunsheng Lin (3): > net: sched: fix packet stuck problem for lockless qdisc > net: sched: fix tx action rescheduling issue during deactivation > net: sched: fix tx action reschedule issue with stopped queue > > include/net/pkt_sched.h | 7 +------ > include/net/sch_generic.h | 35 ++++++++++++++++++++++++++++++++- > net/core/dev.c | 29 ++++++++++++++++++++++----- > net/sched/sch_generic.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-- > 4 files changed, 107 insertions(+), 14 deletions(-) >

1 0

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Alex Williamson 14 May '21

14 May '21

On Thu, 13 May 2021 17:52:56 +0000 Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com> wrote: > Hi Alex, > > > -----Original Message----- > > From: Alex Williamson [mailto:alex.williamson@redhat.com] > > Sent: 13 May 2021 18:04 > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com> > > Cc: Jason Gunthorpe <jgg(a)nvidia.com>; liulongfang > > <liulongfang(a)huawei.com>; cohuck(a)redhat.com; > > linux-kernel(a)vger.kernel.org; linuxarm(a)openeuler.org > > Subject: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to > > vfio > > > > On Thu, 13 May 2021 15:49:25 +0000 > > Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com> > > wrote: > > > > > > -----Original Message----- > > > > From: Jason Gunthorpe [mailto:jgg@nvidia.com] > > > > Sent: 13 May 2021 14:44 > > > > To: liulongfang <liulongfang(a)huawei.com> > > > > Cc: Alex Williamson <alex.williamson(a)redhat.com>; cohuck(a)redhat.com; > > > > linux-kernel(a)vger.kernel.org; linuxarm(a)openeuler.org > > > > Subject: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to > > > > vfio > > > > > > > > On Thu, May 13, 2021 at 10:08:28AM +0800, liulongfang wrote: > > > > > On 2021/5/12 20:10, Jason Gunthorpe wrote: > > > > > > On Wed, May 12, 2021 at 04:39:43PM +0800, liulongfang wrote: > > > > > > > > > > > >> Therefore, this method of limiting the length of the BAR > > > > > >> configuration space can prevent unsafe operations of the memory. > > > > > > > > > > > > The issue is DMA controlled by the guest accessing the secure BAR > > > > > > area, not the guest CPU. > > > > > > > > > > > > Jason > > > > > > . > > > > > > > > > > > This secure BAR area is not presented to the Guest, > > > > > which makes it impossible for the Guest to obtain the secure BAR area > > > > > when establishing the DMA mapping of the configuration space. > > > > > If the DMA controller accesses the secure BAR area, the access will > > > > > be blocked by the SMMU. > > > > > > > > There are scenarios where this is not true. > > > > > > > > At a minimum the mdev driver should refuse to work in those cases. > > > > > > > > > > Hi, > > > > > > I think the idea here is not a generic solution, but a quirk for this specific dev. > > > > > > Something like, > > > > > > --- a/drivers/vfio/pci/vfio_pci.c > > > +++ b/drivers/vfio/pci/vfio_pci.c > > > @@ -866,7 +866,12 @@ static long vfio_pci_ioctl(struct vfio_device > > *core_vdev, > > > break; > > > case VFIO_PCI_BAR0_REGION_INDEX ... > > VFIO_PCI_BAR5_REGION_INDEX: > > > info.offset = > > VFIO_PCI_INDEX_TO_OFFSET(info.index); > > > - info.size = pci_resource_len(pdev, info.index); > > > + > > > + if (check_hisi_acc_quirk(pdev, info)) > > > + info.size = new_size;// BAR is limited > > without migration region. > > > + else > > > + info.size = pci_resource_len(pdev, > > info.index); > > > + > > > if (!info.size) { > > > info.flags = 0; > > > break; > > > > > > Is this an acceptable/workable solution here? > > > > As Jason says, this only restricts CPU access to the BAR, the issue is > > DMA access. As the hardware vendor you may be able to guarantee that > > a DMA transaction generated by the device targeting the remainder of > > the BAR will always go upstream, but can you guarantee the routing > > between the device and the SMMU? For instance if this device can be > > implemented as a plugin card, then it can be installed into a > > downstream port that may not support ACS. That downstream port may > > implement request redirection allowing the transaction to reflect back > > to the device without IOMMU translation. At that point the userspace > > driver can target the kernel driver half of the BAR and potentially > > expose a security risk. Thanks, > > The ACC devices on this platform are not pluggable devices. They are exposed > as integrated endpoint devices. So I am not sure the above concern is valid in this > case. > > I had a look at the userspace driver approach you suggested. But unfortunately > the migration state change for the vf has to check some of the pf registers for > confirming the state. So even if we move the implementation to Qemu, we > still may have to use the migration uAPI to access the pf device registers. > > Since the devices we are concerned here are all integrated endpoints and if the > above quirk is an acceptable one, then we can use the uAPI as done in this > series without overly complicating things here. If you expect this device to appear only as an integrated endpoint, then I think Jason's suggestion above is correct. Your driver that supports migration can refuse to load for devices there the topology is other than expected and you're effectively guaranteeing DMA isolation of the user and in-kernel drivers by hardware DMA semantics and topology. Requiring access to the PF to support the migration protocol also suggests that an in-kernel driver to support migration is our best option. Thanks, Alex

3 2

Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to vfio
by Alex Williamson 14 May '21

14 May '21

On Thu, 13 May 2021 15:49:25 +0000 Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com> wrote: > > -----Original Message----- > > From: Jason Gunthorpe [mailto:jgg@nvidia.com] > > Sent: 13 May 2021 14:44 > > To: liulongfang <liulongfang(a)huawei.com> > > Cc: Alex Williamson <alex.williamson(a)redhat.com>; cohuck(a)redhat.com; > > linux-kernel(a)vger.kernel.org; linuxarm(a)openeuler.org > > Subject: [Linuxarm] Re: [RFC PATCH 2/3] vfio/hisilicon: register the driver to > > vfio > > > > On Thu, May 13, 2021 at 10:08:28AM +0800, liulongfang wrote: > > > On 2021/5/12 20:10, Jason Gunthorpe wrote: > > > > On Wed, May 12, 2021 at 04:39:43PM +0800, liulongfang wrote: > > > > > > > >> Therefore, this method of limiting the length of the BAR > > > >> configuration space can prevent unsafe operations of the memory. > > > > > > > > The issue is DMA controlled by the guest accessing the secure BAR > > > > area, not the guest CPU. > > > > > > > > Jason > > > > . > > > > > > > This secure BAR area is not presented to the Guest, > > > which makes it impossible for the Guest to obtain the secure BAR area > > > when establishing the DMA mapping of the configuration space. > > > If the DMA controller accesses the secure BAR area, the access will > > > be blocked by the SMMU. > > > > There are scenarios where this is not true. > > > > At a minimum the mdev driver should refuse to work in those cases. > > > > Hi, > > I think the idea here is not a generic solution, but a quirk for this specific dev. > > Something like, > > --- a/drivers/vfio/pci/vfio_pci.c > +++ b/drivers/vfio/pci/vfio_pci.c > @@ -866,7 +866,12 @@ static long vfio_pci_ioctl(struct vfio_device *core_vdev, > break; > case VFIO_PCI_BAR0_REGION_INDEX ... VFIO_PCI_BAR5_REGION_INDEX: > info.offset = VFIO_PCI_INDEX_TO_OFFSET(info.index); > - info.size = pci_resource_len(pdev, info.index); > + > + if (check_hisi_acc_quirk(pdev, info)) > + info.size = new_size;// BAR is limited without migration region. > + else > + info.size = pci_resource_len(pdev, info.index); > + > if (!info.size) { > info.flags = 0; > break; > > Is this an acceptable/workable solution here? As Jason says, this only restricts CPU access to the BAR, the issue is DMA access. As the hardware vendor you may be able to guarantee that a DMA transaction generated by the device targeting the remainder of the BAR will always go upstream, but can you guarantee the routing between the device and the SMMU? For instance if this device can be implemented as a plugin card, then it can be installed into a downstream port that may not support ACS. That downstream port may implement request redirection allowing the transaction to reflect back to the device without IOMMU translation. At that point the userspace driver can target the kernel driver half of the BAR and potentially expose a security risk. Thanks, Alex

1 0

[PATCH net v7 0/3] fix packet stuck problem for lockless qdisc
by Yunsheng Lin 13 May '21

13 May '21

This patchset fixes the packet stuck problem mentioned in [1]. Patch 1: Add STATE_MISSED flag to fix packet stuck problem. Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED flag is added in patch 1. Patch 3: Fix the significantly higher CPU consumption problem when multiple threads are competing on a saturated outgoing device. V7: Fix netif_tx_wake_queue() data race noted by Jakub. V6: Some performance optimization in patch 1 suggested by Jakub and drop NET_XMIT_DROP checking in patch 3. V5: add patch 3 to fix the problem reported by Michal Kubecek. V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2. [1]. https://lkml.org/lkml/2019/10/9/42 Yunsheng Lin (3): net: sched: fix packet stuck problem for lockless qdisc net: sched: fix endless tx action reschedule during deactivation net: sched: fix tx action reschedule issue with stopped queue include/net/pkt_sched.h | 7 +------ include/net/sch_generic.h | 35 ++++++++++++++++++++++++++++++++- net/core/dev.c | 29 ++++++++++++++++++++++----- net/sched/sch_generic.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-- 4 files changed, 107 insertions(+), 14 deletions(-) -- 2.7.4

2 5