from:"Jason Wang"

[PATCH] powerpc: Remove the static variable initialisations to 0

2022-07-23 Thread Jason Wang

Initialise global and static variable to 0 is always unnecessary.
Remove the unnecessary initialisations.

Signed-off-by: Jason Wang 
---
 arch/powerpc/kexec/core_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index c2bea9db1c1e..2407214e3f41 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -135,7 +135,7 @@ notrace void kexec_copy_flush(struct kimage *image)
 
 #ifdef CONFIG_SMP
 
-static int kexec_all_irq_disabled = 0;
+static int kexec_all_irq_disabled;
 
 static void kexec_smp_down(void *arg)
 {
-- 
2.35.1

[PATCH] powerpc/ps3: Fix comment typo

2022-07-18 Thread Jason Wang

The double `when' is duplicated in line 1069, remove one.

Signed-off-by: Jason Wang 
---
 drivers/ps3/ps3-lpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ps3/ps3-lpm.c b/drivers/ps3/ps3-lpm.c
index 65512b6cc6fd..200ad8751860 100644
--- a/drivers/ps3/ps3-lpm.c
+++ b/drivers/ps3/ps3-lpm.c
@@ -1066,7 +1066,7 @@ EXPORT_SYMBOL_GPL(ps3_disable_pm_interrupts);
  *  instance, specified by one of enum ps3_lpm_tb_type.
  * @tb_cache: Optional user supplied buffer to use as the trace buffer cache.
  *  If NULL, the driver will allocate and manage an internal buffer.
- *  Unused when when @tb_type is PS3_LPM_TB_TYPE_NONE.
+ *  Unused when @tb_type is PS3_LPM_TB_TYPE_NONE.
  * @tb_cache_size: The size in bytes of the user supplied @tb_cache buffer.
  *  Unused when @tb_cache is NULL or @tb_type is PS3_LPM_TB_TYPE_NONE.
  */
-- 
2.35.1

[PATCH] powerpc/sysdev: Fix comment typo

2022-07-18 Thread Jason Wang

The double `is' is duplicated in line 110, remove one.

Signed-off-by: Jason Wang 
---
 arch/powerpc/sysdev/cpm2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 3f130312b6e9..915f4d3991c3 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -107,7 +107,7 @@ EXPORT_SYMBOL(cpm_command);
  * memory mapped space.
  * The baud rate clock is the system clock divided by something.
  * It was set up long ago during the initial boot phase and is
- * is given to us.
+ * given to us.
  * Baud rate clocks are zero-based in the driver code (as that maps
  * to port numbers).  Documentation uses 1-based numbering.
  */
-- 
2.35.1

[PATCH] KVM: PPC: Book3S HV: Fix comment typo

2022-07-18 Thread Jason Wang

The double `that' is duplicated in line 1604, remove one.

Signed-off-by: Jason Wang 
---
 arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 514fd45c1994..73c6db20cd8a 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -1601,7 +1601,7 @@ long kvm_vm_ioctl_resize_hpt_commit(struct kvm *kvm,
  * is valid, it is written to the HPT as if an H_ENTER with the
  * exact flag set was done.  When the invalid count is non-zero
  * in the header written to the stream, the kernel will make
- * sure that that many HPTEs are invalid, and invalidate them
+ * sure that many HPTEs are invalid, and invalidate them
  * if not.
  */
 
-- 
2.35.1

[PATCH] Merge: Fix comment typo

2022-07-18 Thread Jason Wang

The double `that' is duplicated in line 1604, remove one.

Signed-off-by: Jason Wang 
---
 arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 514fd45c1994..73c6db20cd8a 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -1601,7 +1601,7 @@ long kvm_vm_ioctl_resize_hpt_commit(struct kvm *kvm,
  * is valid, it is written to the HPT as if an H_ENTER with the
  * exact flag set was done.  When the invalid count is non-zero
  * in the header written to the stream, the kernel will make
- * sure that that many HPTEs are invalid, and invalidate them
+ * sure that many HPTEs are invalid, and invalidate them
  * if not.
  */
 
-- 
2.35.1

[PATCH] powerpc/pseries/vas: Fix comment typo

2022-07-18 Thread Jason Wang

The double `the' in line 807 is duplicated, remove one.

Signed-off-by: Jason Wang 
---
 arch/powerpc/platforms/pseries/vas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/vas.c 
b/arch/powerpc/platforms/pseries/vas.c
index 91e7eda0606c..7e6e6dd2e33e 100644
--- a/arch/powerpc/platforms/pseries/vas.c
+++ b/arch/powerpc/platforms/pseries/vas.c
@@ -804,7 +804,7 @@ int vas_reconfig_capabilties(u8 type, int new_nr_creds)
 * The total number of available credits may be decreased or
 * increased with DLPAR operation. Means some windows have to be
 * closed / reopened. Hold the vas_pseries_mutex so that the
-* the user space can not open new windows.
+* user space can not open new windows.
 */
if (old_nr_creds <  new_nr_creds) {
/*
-- 
2.35.1

[PATCH] KVM: PPC: Fix comment typo

2022-07-18 Thread Jason Wang

The double `that' in line 1604 is duplicated, removed one.

Signed-off-by: Jason Wang 
---
 arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 514fd45c1994..73c6db20cd8a 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -1601,7 +1601,7 @@ long kvm_vm_ioctl_resize_hpt_commit(struct kvm *kvm,
  * is valid, it is written to the HPT as if an H_ENTER with the
  * exact flag set was done.  When the invalid count is non-zero
  * in the header written to the stream, the kernel will make
- * sure that that many HPTEs are invalid, and invalidate them
+ * sure that many HPTEs are invalid, and invalidate them
  * if not.
  */
 
-- 
2.35.1

[PATCH] KVM: PPC: Book3S HV: Fix typo in a comment

2022-05-07 Thread Jason Wang

The double `the' in the comment in line 212 is repeated. Remove one
of them from the comment.

Signed-off-by: Jason Wang 
---
 arch/powerpc/kvm/book3s_xive_native.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_xive_native.c 
b/arch/powerpc/kvm/book3s_xive_native.c
index f81ba6f84e72..5271c33fe79e 100644
--- a/arch/powerpc/kvm/book3s_xive_native.c
+++ b/arch/powerpc/kvm/book3s_xive_native.c
@@ -209,7 +209,7 @@ static int kvmppc_xive_native_reset_mapped(struct kvm *kvm, 
unsigned long irq)
 
/*
 * Clear the ESB pages of the IRQ number being mapped (or
-* unmapped) into the guest and let the the VM fault handler
+* unmapped) into the guest and let the VM fault handler
 * repopulate with the appropriate ESB pages (device or IC)
 */
pr_debug("clearing esb pages for girq 0x%lx\n", irq);
-- 
2.35.1

[PATCH] powerpc: use strscpy to copy strings

2021-12-19 Thread Jason Wang

The strlcpy should not be used because it doesn't limit the source
length. So that it will lead some potential bugs.

But the strscpy doesn't require reading memory from the src string
beyond the specified "count" bytes, and since the return value is
easier to error-check than strlcpy()'s. In addition, the implementation
is robust to the string changing out from underneath it, unlike the
current strlcpy() implementation.

Thus, replace strlcpy with strscpy.

Signed-off-by: Jason Wang 
---
 arch/powerpc/platforms/pasemi/misc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pasemi/misc.c 
b/arch/powerpc/platforms/pasemi/misc.c
index 1bf65d02d3ba..06a1ffd43bfe 100644
--- a/arch/powerpc/platforms/pasemi/misc.c
+++ b/arch/powerpc/platforms/pasemi/misc.c
@@ -35,7 +35,7 @@ static int __init find_i2c_driver(struct device_node *node,
for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
if (!of_device_is_compatible(node, i2c_devices[i].of_device))
continue;
-   if (strlcpy(info->type, i2c_devices[i].i2c_type,
+   if (strscpy(info->type, i2c_devices[i].i2c_type,
I2C_NAME_SIZE) >= I2C_NAME_SIZE)
return -ENOMEM;
return 0;
-- 
2.34.1

[PATCH] powerpc/kvm: no need to initialise statics to 0

2021-12-19 Thread Jason Wang

Static variables do not need to be initialised to 0, because compiler
will initialise all uninitialised statics to 0. Thus, remove the
unneeded initialization.

Signed-off-by: Jason Wang 
---
 arch/powerpc/kvm/book3s_64_mmu_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c 
b/arch/powerpc/kvm/book3s_64_mmu_host.c
index c3e31fef0be1..1ae09992c9ea 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -228,7 +228,7 @@ static struct kvmppc_sid_map *create_sid_map(struct 
kvm_vcpu *vcpu, u64 gvsid)
struct kvmppc_sid_map *map;
struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
u16 sid_map_mask;
-   static int backwards_map = 0;
+   static int backwards_map;
 
if (kvmppc_get_msr(vcpu) & MSR_PR)
gvsid |= VSID_PR;
-- 
2.34.1

[PATCH] soc: fsl: qe: fix typo in a comment

2021-12-11 Thread Jason Wang

The double `is' in the comment in line 150 is repeated. Remove one
of them from the comment.

Signed-off-by: Jason Wang 
---
 drivers/soc/fsl/qe/qe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 4d38c80f8be8..b3c226eb5292 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -147,7 +147,7 @@ EXPORT_SYMBOL(qe_issue_cmd);
  * memory mapped space.
  * The BRG clock is the QE clock divided by 2.
  * It was set up long ago during the initial boot phase and is
- * is given to us.
+ * given to us.
  * Baud rate clocks are zero-based in the driver code (as that maps
  * to port numbers). Documentation uses 1-based numbering.
  */
@@ -421,7 +421,7 @@ static void qe_upload_microcode(const void *base,
 
for (i = 0; i < be32_to_cpu(ucode->count); i++)
iowrite32be(be32_to_cpu(code[i]), _immr->iram.idata);
-   
+
/* Set I-RAM Ready Register */
iowrite32be(QE_IRAM_READY, _immr->iram.iready);
 }
-- 
2.34.1

[PATCH] powerpc: tsi108: make EXPORT_SYMBOL follow its function immediately

2021-11-14 Thread Jason Wang

EXPORT_SYMBOL(foo); should immediately follow its function/variable.

Signed-off-by: Jason Wang 
---
 arch/powerpc/sysdev/tsi108_dev.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/tsi108_dev.c b/arch/powerpc/sysdev/tsi108_dev.c
index 4c4a6efd5e5f..9e13fb35ed5c 100644
--- a/arch/powerpc/sysdev/tsi108_dev.c
+++ b/arch/powerpc/sysdev/tsi108_dev.c
@@ -51,13 +51,12 @@ phys_addr_t get_csrbase(void)
}
return tsi108_csr_base;
 }
+EXPORT_SYMBOL(get_csrbase);
 
 u32 get_vir_csrbase(void)
 {
return (u32) (ioremap(get_csrbase(), 0x1));
 }
-
-EXPORT_SYMBOL(get_csrbase);
 EXPORT_SYMBOL(get_vir_csrbase);
 
 static int __init tsi108_eth_of_init(void)
-- 
2.33.0

[PATCH] soc: fsl: qe: Fix typo in a comment

2021-11-12 Thread Jason Wang

The double `is' in a comment is repeated, thus one of them
should be removed.

Signed-off-by: Jason Wang 
---
 drivers/soc/fsl/qe/qe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 4d38c80f8be8..b3c226eb5292 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -147,7 +147,7 @@ EXPORT_SYMBOL(qe_issue_cmd);
  * memory mapped space.
  * The BRG clock is the QE clock divided by 2.
  * It was set up long ago during the initial boot phase and is
- * is given to us.
+ * given to us.
  * Baud rate clocks are zero-based in the driver code (as that maps
  * to port numbers). Documentation uses 1-based numbering.
  */
@@ -421,7 +421,7 @@ static void qe_upload_microcode(const void *base,
 
for (i = 0; i < be32_to_cpu(ucode->count); i++)
iowrite32be(be32_to_cpu(code[i]), _immr->iram.idata);
-   
+
/* Set I-RAM Ready Register */
iowrite32be(QE_IRAM_READY, _immr->iram.iready);
 }
-- 
2.33.0

[PATCH] mm: Remove a repeated word in a comment

2021-11-12 Thread Jason Wang

The double word `up' in a comment is repeated, thus one of
them should be removed.

Signed-off-by: Jason Wang 
---
 drivers/macintosh/mediabay.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index eab7e83c11c4..ec23094263e7 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -129,7 +129,7 @@ enum {
 /*
  * Functions for polling content of media bay
  */
- 
+
 static u8
 ohare_mb_content(struct media_bay_info *bay)
 {
@@ -331,12 +331,12 @@ static void keylargo_mb_un_reset_ide(struct 
media_bay_info* bay)
 
 static inline void set_mb_power(struct media_bay_info* bay, int onoff)
 {
-   /* Power up up and assert the bay reset line */
+   /* Power up and assert the bay reset line */
if (onoff) {
bay->ops->power(bay, 1);
bay->state = mb_powering_up;
pr_debug("mediabay%d: powering up\n", bay->index);
-   } else { 
+   } else {
/* Make sure everything is powered down & disabled */
bay->ops->power(bay, 0);
bay->state = mb_powering_down;
@@ -577,7 +577,7 @@ static int media_bay_attach(struct macio_dev *mdev,
macio_release_resources(mdev);
return -ENOMEM;
}
-   
+
i = media_bay_count++;
bay = _bays[i];
bay->mdev = mdev;
@@ -745,7 +745,7 @@ static int __init media_bay_init(void)
if (!machine_is(powermac))
return 0;
 
-   macio_register_driver(_bay_driver);   
+   macio_register_driver(_bay_driver);
 
return 0;
 }
-- 
2.33.0

[PATCH] macintosh: no need to initilise statics to 0

2021-08-17 Thread Jason Wang

Global static variables dont need to be initialised to 0. Because
the compiler will initilise them.

Signed-off-by: Jason Wang 
---
 drivers/macintosh/mediabay.c | 10 ++---
 drivers/macintosh/via-pmu.c  | 78 ++--
 2 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index eab7e83c11c4..e104a95decb5 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -70,7 +70,7 @@ struct media_bay_info {
 #define MAX_BAYS   2
 
 static struct media_bay_info media_bays[MAX_BAYS];
-static int media_bay_count = 0;
+static int media_bay_count;
 
 /*
  * Wait that number of ms between each step in normal polling mode
@@ -129,7 +129,7 @@ enum {
 /*
  * Functions for polling content of media bay
  */
- 
+
 static u8
 ohare_mb_content(struct media_bay_info *bay)
 {
@@ -336,7 +336,7 @@ static inline void set_mb_power(struct media_bay_info* bay, 
int onoff)
bay->ops->power(bay, 1);
bay->state = mb_powering_up;
pr_debug("mediabay%d: powering up\n", bay->index);
-   } else { 
+   } else {
/* Make sure everything is powered down & disabled */
bay->ops->power(bay, 0);
bay->state = mb_powering_down;
@@ -577,7 +577,7 @@ static int media_bay_attach(struct macio_dev *mdev,
macio_release_resources(mdev);
return -ENOMEM;
}
-   
+
i = media_bay_count++;
bay = _bays[i];
bay->mdev = mdev;
@@ -745,7 +745,7 @@ static int __init media_bay_init(void)
if (!machine_is(powermac))
return 0;
 
-   macio_register_driver(_bay_driver);   
+   macio_register_driver(_bay_driver);
 
return 0;
 }
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 4bdd4c45e7a7..cba4c2464dbf 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -158,7 +158,7 @@ static struct device_node *vias;
 static struct device_node *gpio_node;
 #endif
 static unsigned char __iomem *gpio_reg;
-static int gpio_irq = 0;
+static int gpio_irq;
 static int gpio_irq_enabled = -1;
 static volatile int pmu_suspended;
 static spinlock_t pmu_lock;
@@ -313,7 +313,7 @@ int __init find_via_pmu(void)
PMU_INT_SNDBRT |
PMU_INT_ADB |
PMU_INT_TICK;
-   
+
if (of_node_name_eq(vias->parent, "ohare") ||
of_device_is_compatible(vias->parent, "ohare"))
pmu_kind = PMU_OHARE_BASED;
@@ -336,7 +336,7 @@ int __init find_via_pmu(void)
PMU_INT_ADB |
PMU_INT_TICK |
PMU_INT_ENVIRONMENT;
-   
+
gpiop = of_find_node_by_name(NULL, "gpio");
if (gpiop) {
reg = of_get_property(gpiop, "reg", NULL);
@@ -358,7 +358,7 @@ int __init find_via_pmu(void)
printk(KERN_ERR "via-pmu: Can't map address !\n");
goto fail_via_remap;
}
-   
+
out_8([IER], IER_CLR | 0x7f);  /* disable all intrs */
out_8([IFR], 0x7f);/* clear IFR */
 
@@ -368,7 +368,7 @@ int __init find_via_pmu(void)
goto fail_init;
 
sys_ctrler = SYS_CTRLER_PMU;
-   
+
return 1;
 
  fail_init:
@@ -623,7 +623,7 @@ init_pmu(void)
pmu_wait_complete();
if (req.reply_len > 0)
pmu_version = req.reply[0];
-   
+
/* Read server mode setting */
if (pmu_kind == PMU_KEYLARGO_BASED) {
pmu_request(, NULL, 2, PMU_POWER_EVENTS,
@@ -664,11 +664,11 @@ static void pmu_set_server_mode(int server_mode)
if (server_mode)
pmu_request(, NULL, 4, PMU_POWER_EVENTS,
PMU_PWR_SET_POWERUP_EVENTS,
-   req.reply[0], PMU_PWR_WAKEUP_AC_INSERT); 
+   req.reply[0], PMU_PWR_WAKEUP_AC_INSERT);
else
pmu_request(, NULL, 4, PMU_POWER_EVENTS,
PMU_PWR_CLR_POWERUP_EVENTS,
-   req.reply[0], PMU_PWR_WAKEUP_AC_INSERT); 
+   req.reply[0], PMU_PWR_WAKEUP_AC_INSERT);
pmu_wait_complete();
 }
 
@@ -684,8 +684,8 @@ done_battery_state_ohare(struct adb_request* req)
 *0x01 :  AC indicator
 *0x02 :  charging
 *0x04 :  battery exist
-*0x08 :  
-*0x10 :  
+*0x08 :
+*0x10 :
 *0x20 :  full charged
 *0x40 :  pcharge reset
 *0x80 :  battery exist
@@ -708,7 +708,7 @@ done_battery_state_ohare(struct adb_request* req)
pmu_power_flags |= PMU_PWR_AC_PRESEN

[PATCH] powerpc: use strscpy to replace strlcpy

2021-08-07 Thread Jason Wang

The strlcpy should not be used because it doesn't limit the source
length. As linus says, it's a completely useless function if you
can't implicitly trust the source string - but that is almost always
why people think they should use it! All in all the BSD function
will lead some potential bugs.

But the strscpy doesn't require reading memory from the src string
beyond the specified "count" bytes, and since the return value is
easier to error-check than strlcpy()'s. In addition, the implementation
is robust to the string changing out from underneath it, unlike the
current strlcpy() implementation.

Thus, We prefer using strscpy instead of strlcpy.

Signed-off-by: Jason Wang 
---
 arch/powerpc/platforms/powermac/bootx_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powermac/bootx_init.c 
b/arch/powerpc/platforms/powermac/bootx_init.c
index d20ef35e6d9d..741aa5b89e55 100644
--- a/arch/powerpc/platforms/powermac/bootx_init.c
+++ b/arch/powerpc/platforms/powermac/bootx_init.c
@@ -243,7 +243,7 @@ static void __init bootx_scan_dt_build_strings(unsigned 
long base,
DBG(" detected display ! adding properties names !\n");
bootx_dt_add_string("linux,boot-display", mem_end);
bootx_dt_add_string("linux,opened", mem_end);
-   strlcpy(bootx_disp_path, namep, sizeof(bootx_disp_path));
+   strscpy(bootx_disp_path, namep, sizeof(bootx_disp_path));
}
 
/* get and store all property names */
-- 
2.32.0

[PATCH] powerpc/perf/24x7: use 'unsigned int' instead of 'unsigned'

2021-07-29 Thread Jason Wang

Replace the 'unsigned' with 'unsigned int' which is more accurate.

Signed-off-by: Jason Wang 
---
 arch/powerpc/perf/hv-24x7.c | 38 ++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 1816f560a465..d767724a1162 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -33,7 +33,7 @@ static bool aggregate_result_elements;
 
 static cpumask_t hv_24x7_cpumask;
 
-static bool domain_is_valid(unsigned domain)
+static bool domain_is_valid(unsigned int domain)
 {
switch (domain) {
 #define DOMAIN(n, v, x, c) \
@@ -47,7 +47,7 @@ static bool domain_is_valid(unsigned domain)
}
 }
 
-static bool is_physical_domain(unsigned domain)
+static bool is_physical_domain(unsigned int domain)
 {
switch (domain) {
 #define DOMAIN(n, v, x, c) \
@@ -128,7 +128,7 @@ static bool domain_needs_aggregation(unsigned int domain)
  domain <= HV_PERF_DOMAIN_VCPU_REMOTE_NODE));
 }
 
-static const char *domain_name(unsigned domain)
+static const char *domain_name(unsigned int domain)
 {
if (!domain_is_valid(domain))
return NULL;
@@ -146,7 +146,7 @@ static const char *domain_name(unsigned domain)
return NULL;
 }
 
-static bool catalog_entry_domain_is_valid(unsigned domain)
+static bool catalog_entry_domain_is_valid(unsigned int domain)
 {
/* POWER8 doesn't support virtual domains. */
if (interface_version == 1)
@@ -258,7 +258,7 @@ static char *event_name(struct hv_24x7_event_data *ev, int 
*len)
 
 static char *event_desc(struct hv_24x7_event_data *ev, int *len)
 {
-   unsigned nl = be16_to_cpu(ev->event_name_len);
+   unsigned int nl = be16_to_cpu(ev->event_name_len);
__be16 *desc_len = (__be16 *)(ev->remainder + nl - 2);
 
*len = be16_to_cpu(*desc_len) - 2;
@@ -267,9 +267,9 @@ static char *event_desc(struct hv_24x7_event_data *ev, int 
*len)
 
 static char *event_long_desc(struct hv_24x7_event_data *ev, int *len)
 {
-   unsigned nl = be16_to_cpu(ev->event_name_len);
+   unsigned int nl = be16_to_cpu(ev->event_name_len);
__be16 *desc_len_ = (__be16 *)(ev->remainder + nl - 2);
-   unsigned desc_len = be16_to_cpu(*desc_len_);
+   unsigned int desc_len = be16_to_cpu(*desc_len_);
__be16 *long_desc_len = (__be16 *)(ev->remainder + nl + desc_len - 2);
 
*len = be16_to_cpu(*long_desc_len) - 2;
@@ -296,8 +296,8 @@ static void *event_end(struct hv_24x7_event_data *ev, void 
*end)
 {
void *start = ev;
__be16 *dl_, *ldl_;
-   unsigned dl, ldl;
-   unsigned nl = be16_to_cpu(ev->event_name_len);
+   unsigned int dl, ldl;
+   unsigned int nl = be16_to_cpu(ev->event_name_len);
 
if (nl < 2) {
pr_debug("%s: name length too short: %d", __func__, nl);
@@ -398,7 +398,7 @@ static long h_get_24x7_catalog_page(char page[], u64 
version, u32 index)
  * - Specifying (i.e overriding) values for other parameters
  *   is undefined.
  */
-static char *event_fmt(struct hv_24x7_event_data *event, unsigned domain)
+static char *event_fmt(struct hv_24x7_event_data *event, unsigned int domain)
 {
const char *sindex;
const char *lpar;
@@ -529,9 +529,9 @@ static struct attribute *device_str_attr_create(char *name, 
int name_max,
return NULL;
 }
 
-static struct attribute *event_to_attr(unsigned ix,
+static struct attribute *event_to_attr(unsigned int ix,
   struct hv_24x7_event_data *event,
-  unsigned domain,
+  unsigned int domain,
   int nonce)
 {
int event_name_len;
@@ -599,7 +599,7 @@ event_to_long_desc_attr(struct hv_24x7_event_data *event, 
int nonce)
return device_str_attr_create(name, nl, nonce, desc, dl);
 }
 
-static int event_data_to_attrs(unsigned ix, struct attribute **attrs,
+static int event_data_to_attrs(unsigned int ix, struct attribute **attrs,
   struct hv_24x7_event_data *event, int nonce)
 {
*attrs = event_to_attr(ix, event, event->domain, nonce);
@@ -614,8 +614,8 @@ struct event_uniq {
struct rb_node node;
const char *name;
int nl;
-   unsigned ct;
-   unsigned domain;
+   unsigned int ct;
+   unsigned int domain;
 };
 
 static int memord(const void *d1, size_t s1, const void *d2, size_t s2)
@@ -628,8 +628,8 @@ static int memord(const void *d1, size_t s1, const void 
*d2, size_t s2)
return memcmp(d1, d2, s1);
 }
 
-static int ev_uniq_ord(const void *v1, size_t s1, unsigned d1, const void *v2,
-  size_t s2, unsigned d2)
+static int ev_uniq_ord(const void *v1, size_t s1, unsigned int d1,
+   const void *v2

[PATCH] powerpc/xmon: use ARRAY_SIZE

2021-07-25 Thread Jason Wang

The ARRAY_SIZE is the macro definition of sizeof(a)/sizeof(a[0]) and
it is more compact and formal to get a array size.

Signed-off-by: Jason Wang 
---
 arch/powerpc/xmon/ppc-opc.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/xmon/ppc-opc.c b/arch/powerpc/xmon/ppc-opc.c
index dfb80810b16c..6ca4cd26caef 100644
--- a/arch/powerpc/xmon/ppc-opc.c
+++ b/arch/powerpc/xmon/ppc-opc.c
@@ -954,8 +954,7 @@ const struct powerpc_operand powerpc_operands[] =
   { 0xff, 11, NULL, NULL, PPC_OPERAND_SIGNOPT },
 };
 
-const unsigned int num_powerpc_operands = (sizeof (powerpc_operands)
-  / sizeof (powerpc_operands[0]));
+const unsigned int num_powerpc_operands = ARRAY_SIZE(powerpc_operands);
 
 /* The functions used to insert and extract complicated operands.  */
 
@@ -6968,8 +6967,7 @@ const struct powerpc_opcode powerpc_opcodes[] = {
 {"fcfidu.",XRC(63,974,1),  XRA_MASK, POWER7|PPCA2, PPCVLE, {FRT, 
FRB}},
 };
 
-const int powerpc_num_opcodes =
-  sizeof (powerpc_opcodes) / sizeof (powerpc_opcodes[0]);
+const int powerpc_num_opcodes = ARRAY_SIZE(powerpc_opcodes);
 
 /* The VLE opcode table.
 
@@ -7207,8 +7205,7 @@ const struct powerpc_opcode vle_opcodes[] = {
 {"se_bl",  BD8(58,0,1),BD8_MASK,   PPCVLE, 0,  {B8}},
 };
 
-const int vle_num_opcodes =
-  sizeof (vle_opcodes) / sizeof (vle_opcodes[0]);
+const int vle_num_opcodes = ARRAY_SIZE(vle_opcodes);
 
 /* The macro table.  This is only used by the assembler.  */
 
@@ -7276,5 +7273,4 @@ const struct powerpc_macro powerpc_macros[] = {
 {"e_clrlslwi",4, PPCVLE, "e_rlwinm %0,%1,%3,(%2)-(%3),31-(%3)"},
 };
 
-const int powerpc_num_macros =
-  sizeof (powerpc_macros) / sizeof (powerpc_macros[0]);
+const int powerpc_num_macros = ARRAY_SIZE(powerpc_macros);
-- 
2.32.0

[PATCH v2] sched: Use BUG_ON

2021-07-01 Thread Jason Wang

The BUG_ON macro simplifies the if condition followed by BUG, so that
we can use BUG_ON instead of if condition followed by BUG.

Signed-off-by: Jason Wang 
---
 arch/powerpc/platforms/cell/spufs/sched.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/sched.c 
b/arch/powerpc/platforms/cell/spufs/sched.c
index 369206489895..0f218d9e5733 100644
--- a/arch/powerpc/platforms/cell/spufs/sched.c
+++ b/arch/powerpc/platforms/cell/spufs/sched.c
@@ -904,8 +904,8 @@ static noinline void spusched_tick(struct spu_context *ctx)
struct spu_context *new = NULL;
struct spu *spu = NULL;
 
-   if (spu_acquire(ctx))
-   BUG();  /* a kernel thread never has signals pending */
+   /* a kernel thread never has signals pending */
+   BUG_ON(spu_acquire(ctx));
 
if (ctx->state != SPU_STATE_RUNNABLE)
goto out;
-- 
2.32.0

[PATCH] sched: Use WARN_ON

2021-07-01 Thread Jason Wang

The BUG_ON macro simplifies the if condition followed by BUG, but it
will lead to the kernel crashing. Therefore, we can try using WARN_ON
instead of if condition followed by BUG.

Signed-off-by: Jason Wang 
---
 arch/powerpc/platforms/cell/spufs/sched.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/sched.c 
b/arch/powerpc/platforms/cell/spufs/sched.c
index 369206489895..0f218d9e5733 100644
--- a/arch/powerpc/platforms/cell/spufs/sched.c
+++ b/arch/powerpc/platforms/cell/spufs/sched.c
@@ -904,8 +904,8 @@ static noinline void spusched_tick(struct spu_context *ctx)
struct spu_context *new = NULL;
struct spu *spu = NULL;
 
-   if (spu_acquire(ctx))
-   BUG();  /* a kernel thread never has signals pending */
+   /* a kernel thread never has signals pending */
+   WARN_ON(spu_acquire(ctx));
 
if (ctx->state != SPU_STATE_RUNNABLE)
goto out;
-- 
2.32.0

[PATCH] powerpc/xmon: Use ARRAY_SIZE

2021-07-01 Thread Jason Wang

The ARRAY_SIZE macro is more compact and formal to get array size in
linux kernel source. In addition, it is more readable for kernel
developpers. Thus, we can replace all sizeof(arr)/sizeof(arr[0]) with
ARRAY_SIZE.

Signed-off-by: Jason Wang 
---
 arch/powerpc/xmon/ppc-opc.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/xmon/ppc-opc.c b/arch/powerpc/xmon/ppc-opc.c
index dfb80810b16c..e1d292fe6c6e 100644
--- a/arch/powerpc/xmon/ppc-opc.c
+++ b/arch/powerpc/xmon/ppc-opc.c
@@ -954,8 +954,7 @@ const struct powerpc_operand powerpc_operands[] =
   { 0xff, 11, NULL, NULL, PPC_OPERAND_SIGNOPT },
 };
 
-const unsigned int num_powerpc_operands = (sizeof (powerpc_operands)
-  / sizeof (powerpc_operands[0]));
+const unsigned int num_powerpc_operands = ARRAY_SIZE(powerpc_operands);
 
 /* The functions used to insert and extract complicated operands.  */
 
@@ -6968,9 +6967,8 @@ const struct powerpc_opcode powerpc_opcodes[] = {
 {"fcfidu.",XRC(63,974,1),  XRA_MASK, POWER7|PPCA2, PPCVLE, {FRT, 
FRB}},
 };
 
-const int powerpc_num_opcodes =
-  sizeof (powerpc_opcodes) / sizeof (powerpc_opcodes[0]);
-
+const int powerpc_num_opcodes = ARRAY_SIZE(powerpc_opcodes);
+
 /* The VLE opcode table.
 
The format of this opcode table is the same as the main opcode table.  */
@@ -7207,9 +7205,8 @@ const struct powerpc_opcode vle_opcodes[] = {
 {"se_bl",  BD8(58,0,1),BD8_MASK,   PPCVLE, 0,  {B8}},
 };
 
-const int vle_num_opcodes =
-  sizeof (vle_opcodes) / sizeof (vle_opcodes[0]);
-
+const int vle_num_opcodes = ARRAY_SIZE(vle_opcodes);
+
 /* The macro table.  This is only used by the assembler.  */
 
 /* The expressions of the form (-x ! 31) & (x | 31) have the value 0
@@ -7276,5 +7273,4 @@ const struct powerpc_macro powerpc_macros[] = {
 {"e_clrlslwi",4, PPCVLE, "e_rlwinm %0,%1,%3,(%2)-(%3),31-(%3)"},
 };
 
-const int powerpc_num_macros =
-  sizeof (powerpc_macros) / sizeof (powerpc_macros[0]);
+const int powerpc_num_macros = ARRAY_SIZE(powerpc_macros);
-- 
2.31.1

[PATCH] powerpc/sysfs: Replace sizeof(arr)/sizeof(arr[0]) with ARRAY_SIZE

2021-06-24 Thread Jason Wang

The ARRAY_SIZE macro is more compact and more formal in linux source.

Signed-off-by: Jason Wang 
---
 arch/powerpc/kernel/sysfs.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 2e08640bb3b4..5ff0e55d0db1 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -843,14 +843,14 @@ static int register_cpu_online(unsigned int cpu)
 #ifdef HAS_PPC_PMC_IBM
case PPC_PMC_IBM:
attrs = ibm_common_attrs;
-   nattrs = sizeof(ibm_common_attrs) / sizeof(struct 
device_attribute);
+   nattrs = ARRAY_SIZE(ibm_common_attrs);
pmc_attrs = classic_pmc_attrs;
break;
 #endif /* HAS_PPC_PMC_IBM */
 #ifdef HAS_PPC_PMC_G4
case PPC_PMC_G4:
attrs = g4_common_attrs;
-   nattrs = sizeof(g4_common_attrs) / sizeof(struct 
device_attribute);
+   nattrs = ARRAY_SIZE(g4_common_attrs);
pmc_attrs = classic_pmc_attrs;
break;
 #endif /* HAS_PPC_PMC_G4 */
@@ -858,7 +858,7 @@ static int register_cpu_online(unsigned int cpu)
case PPC_PMC_PA6T:
/* PA Semi starts counting at PMC0 */
attrs = pa6t_attrs;
-   nattrs = sizeof(pa6t_attrs) / sizeof(struct device_attribute);
+   nattrs = ARRAY_SIZE(pa6t_attrs);
pmc_attrs = NULL;
break;
 #endif
@@ -940,14 +940,14 @@ static int unregister_cpu_online(unsigned int cpu)
 #ifdef HAS_PPC_PMC_IBM
case PPC_PMC_IBM:
attrs = ibm_common_attrs;
-   nattrs = sizeof(ibm_common_attrs) / sizeof(struct 
device_attribute);
+   nattrs = ARRAY_SIZE(ibm_common_attrs);
pmc_attrs = classic_pmc_attrs;
break;
 #endif /* HAS_PPC_PMC_IBM */
 #ifdef HAS_PPC_PMC_G4
case PPC_PMC_G4:
attrs = g4_common_attrs;
-   nattrs = sizeof(g4_common_attrs) / sizeof(struct 
device_attribute);
+   nattrs = ARRAY_SIZE(g4_common_attrs);
pmc_attrs = classic_pmc_attrs;
break;
 #endif /* HAS_PPC_PMC_G4 */
@@ -955,7 +955,7 @@ static int unregister_cpu_online(unsigned int cpu)
case PPC_PMC_PA6T:
/* PA Semi starts counting at PMC0 */
attrs = pa6t_attrs;
-   nattrs = sizeof(pa6t_attrs) / sizeof(struct device_attribute);
+   nattrs = ARRAY_SIZE(pa6t_attrs);
pmc_attrs = NULL;
break;
 #endif
-- 
2.31.1

Re: [PATCH] arm64: defconfig: enable modern virtio pci device

2021-02-17 Thread Jason Wang




On 2021/2/11 下午7:52, Arnd Bergmann wrote:

On Wed, Feb 10, 2021 at 8:05 PM Anders Roxell  wrote:

Since patch ("virtio-pci: introduce modern device module") got added it
is not possible to boot a defconfig kernel in qemu with a virtio pci
device.  Add CONFIG_VIRTIO_PCI_MODERN=y fragment makes the kernel able
to boot.

Signed-off-by: Anders Roxell 
---
  arch/arm/configs/multi_v7_defconfig | 1 +
  arch/arm64/configs/defconfig| 1 +

Acked-by: Arnd Bergmann 

Michael, can you pick this up in the vhost tree that introduces the regression?

  Arnd



Hi:

Based on the discussion previously, the plan is to select 
VIRTIO_PCI_MODERN, and document the module that select it must depend on 
PCI.


I will post a patch soon.

Thanks

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang




On 2020/4/17 下午5:38, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 05:33:56PM +0800, Jason Wang wrote:

On 2020/4/17 下午5:01, Michael S. Tsirkin wrote:

There could be some misunderstanding here. I thought it's somehow similar: a
CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is
not set.

Thanks


BTW do entries with no prompt actually appear in defconfig?


Yes. I can see CONFIG_VHOST_DPN=y after make ARCH=m68k defconfig

You see it in .config right? So that's harmless right?



Yes.

Thanks

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang




On 2020/4/17 下午5:01, Michael S. Tsirkin wrote:

There could be some misunderstanding here. I thought it's somehow similar: a
CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is
not set.

Thanks


BTW do entries with no prompt actually appear in defconfig?



Yes. I can see CONFIG_VHOST_DPN=y after make ARCH=m68k defconfig

Thanks

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang




On 2020/4/17 下午5:25, Geert Uytterhoeven wrote:

Hi Michael,

On Fri, Apr 17, 2020 at 10:57 AM Michael S. Tsirkin  wrote:

On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote:

On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:

On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:

On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:

On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:

On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:

We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
without the caring of CONFIG_VHOST.

But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
for the ones that doesn't want vhost. So it actually shifts the
burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
not set". So this patch tries to enable CONFIG_VHOST explicitly in
defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.

Acked-by: Christian Borntraeger(s390)
Acked-by: Michael Ellerman(powerpc)
Cc: Thomas Bogendoerfer
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Reported-by: Geert Uytterhoeven
Signed-off-by: Jason Wang

I rebased this on top of OABI fix since that
seems more orgent to fix.
Pushed to my vhost branch pls take a look and
if possible test.
Thanks!

I test this patch by generating the defconfigs that wants vhost_net or
vhost_vsock. All looks fine.

But having CONFIG_VHOST_DPN=y may end up with the similar situation that
this patch want to address.
Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
menuconfig for VHOST_RING and do something similar?

Thanks

Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
an internal variable for the OABI fix. I kept it separate
so it's easy to revert for 5.8. Yes we could squash it into
VHOST directly but I don't see how that changes logic at all.

Sorry for being unclear.

I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
in the defconfigs.

But who cares?

FYI, please seehttps://www.spinics.net/lists/kvm/msg212685.html

The complaint was not about the symbol IIUC.  It was that we caused
everyone to build vhost unless they manually disabled it.

There could be some misunderstanding here. I thought it's somehow similar: a
CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is
not set.

Thanks

Hmm. So looking at Documentation/kbuild/kconfig-language.rst :

 Things that merit "default y/m" include:

 a) A new Kconfig option for something that used to always be built
should be "default y".

 b) A new gatekeeping Kconfig option that hides/shows other Kconfig
options (but does not generate any code of its own), should be
"default y" so people will see those other options.

 c) Sub-driver behavior or similar options for a driver that is
"default n". This allows you to provide sane defaults.


So it looks like VHOST_MENU is actually matching rule b).
So what's the problem we are trying to solve with this patch, exactly?

Geert could you clarify pls?

I can confirm VHOST_MENU is matching rule b), so it is safe to always
enable it.

Gr{oetje,eeting}s,

 Geert



Right, so I think we can drop this patch.

Thanks

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang




On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:

On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:

On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:

On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:

On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:

We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
without the caring of CONFIG_VHOST.

But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
for the ones that doesn't want vhost. So it actually shifts the
burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
not set". So this patch tries to enable CONFIG_VHOST explicitly in
defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.

Acked-by: Christian Borntraeger   (s390)
Acked-by: Michael Ellerman   (powerpc)
Cc: Thomas Bogendoerfer
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Reported-by: Geert Uytterhoeven
Signed-off-by: Jason Wang

I rebased this on top of OABI fix since that
seems more orgent to fix.
Pushed to my vhost branch pls take a look and
if possible test.
Thanks!

I test this patch by generating the defconfigs that wants vhost_net or
vhost_vsock. All looks fine.

But having CONFIG_VHOST_DPN=y may end up with the similar situation that
this patch want to address.
Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
menuconfig for VHOST_RING and do something similar?

Thanks

Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
an internal variable for the OABI fix. I kept it separate
so it's easy to revert for 5.8. Yes we could squash it into
VHOST directly but I don't see how that changes logic at all.

Sorry for being unclear.

I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
in the defconfigs.

But who cares?

FYI, please seehttps://www.spinics.net/lists/kvm/msg212685.html

The complaint was not about the symbol IIUC.  It was that we caused
everyone to build vhost unless they manually disabled it.



There could be some misunderstanding here. I thought it's somehow 
similar: a CONFIG_VHOST_MENU=y will be left in the defconfigs even if 
CONFIG_VHOST is not set.


Thanks

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang




On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:

On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:

On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:

On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:

We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
without the caring of CONFIG_VHOST.

But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
for the ones that doesn't want vhost. So it actually shifts the
burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
not set". So this patch tries to enable CONFIG_VHOST explicitly in
defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.

Acked-by: Christian Borntraeger  (s390)
Acked-by: Michael Ellerman  (powerpc)
Cc: Thomas Bogendoerfer
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Reported-by: Geert Uytterhoeven
Signed-off-by: Jason Wang

I rebased this on top of OABI fix since that
seems more orgent to fix.
Pushed to my vhost branch pls take a look and
if possible test.
Thanks!

I test this patch by generating the defconfigs that wants vhost_net or
vhost_vsock. All looks fine.

But having CONFIG_VHOST_DPN=y may end up with the similar situation that
this patch want to address.
Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
menuconfig for VHOST_RING and do something similar?

Thanks

Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
an internal variable for the OABI fix. I kept it separate
so it's easy to revert for 5.8. Yes we could squash it into
VHOST directly but I don't see how that changes logic at all.


Sorry for being unclear.

I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be left
in the defconfigs.

But who cares?



FYI, please see https://www.spinics.net/lists/kvm/msg212685.html



That does not add any code, does it?



It doesn't.

Thanks





This requires the arch maintainers to add
"CONFIG_VHOST_VDPN is not set". (Geert complains about this)

Thanks

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-17 Thread Jason Wang




On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:

On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:

On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:

On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:

We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
without the caring of CONFIG_VHOST.

But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
for the ones that doesn't want vhost. So it actually shifts the
burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
not set". So this patch tries to enable CONFIG_VHOST explicitly in
defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.

Acked-by: Christian Borntraeger  (s390)
Acked-by: Michael Ellerman  (powerpc)
Cc: Thomas Bogendoerfer
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Reported-by: Geert Uytterhoeven
Signed-off-by: Jason Wang

I rebased this on top of OABI fix since that
seems more orgent to fix.
Pushed to my vhost branch pls take a look and
if possible test.
Thanks!


I test this patch by generating the defconfigs that wants vhost_net or
vhost_vsock. All looks fine.

But having CONFIG_VHOST_DPN=y may end up with the similar situation that
this patch want to address.
Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another
menuconfig for VHOST_RING and do something similar?

Thanks

Sorry I don't understand. After this patch CONFIG_VHOST_DPN is just
an internal variable for the OABI fix. I kept it separate
so it's easy to revert for 5.8. Yes we could squash it into
VHOST directly but I don't see how that changes logic at all.



Sorry for being unclear.

I meant since it was enabled by default, "CONFIG_VHOST_DPN=y" will be 
left in the defconfigs. This requires the arch maintainers to add 
"CONFIG_VHOST_VDPN is not set". (Geert complains about this)


Thanks

Re: [PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-16 Thread Jason Wang




On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:

On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:

We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
without the caring of CONFIG_VHOST.

But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
for the ones that doesn't want vhost. So it actually shifts the
burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
not set". So this patch tries to enable CONFIG_VHOST explicitly in
defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.

Acked-by: Christian Borntraeger  (s390)
Acked-by: Michael Ellerman  (powerpc)
Cc: Thomas Bogendoerfer
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Reported-by: Geert Uytterhoeven
Signed-off-by: Jason Wang

I rebased this on top of OABI fix since that
seems more orgent to fix.
Pushed to my vhost branch pls take a look and
if possible test.
Thanks!



I test this patch by generating the defconfigs that wants vhost_net or 
vhost_vsock. All looks fine.


But having CONFIG_VHOST_DPN=y may end up with the similar situation that 
this patch want to address.


Maybe we can let CONFIG_VHOST depends on !ARM || AEABI then add another 
menuconfig for VHOST_RING and do something similar?


Thanks

[PATCH V2] vhost: do not enable VHOST_MENU by default

2020-04-14 Thread Jason Wang

We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
without the caring of CONFIG_VHOST.

But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
for the ones that doesn't want vhost. So it actually shifts the
burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
not set". So this patch tries to enable CONFIG_VHOST explicitly in
defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.

Acked-by: Christian Borntraeger  (s390)
Acked-by: Michael Ellerman  (powerpc)
Cc: Thomas Bogendoerfer 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Reported-by: Geert Uytterhoeven 
Signed-off-by: Jason Wang 
---
Change since V1:
- depends on EVENTFD for VHOST
---
 arch/mips/configs/malta_kvm_defconfig  |  1 +
 arch/powerpc/configs/powernv_defconfig |  1 +
 arch/powerpc/configs/ppc64_defconfig   |  1 +
 arch/powerpc/configs/pseries_defconfig |  1 +
 arch/s390/configs/debug_defconfig  |  1 +
 arch/s390/configs/defconfig|  1 +
 drivers/vhost/Kconfig  | 26 +-
 7 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/arch/mips/configs/malta_kvm_defconfig 
b/arch/mips/configs/malta_kvm_defconfig
index 8ef612552a19..06f0c7a0ca87 100644
--- a/arch/mips/configs/malta_kvm_defconfig
+++ b/arch/mips/configs/malta_kvm_defconfig
@@ -18,6 +18,7 @@ CONFIG_PCI=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM=m
 CONFIG_KVM_MIPS_DEBUG_COP0_COUNTERS=y
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
index 71749377d164..404245b4594d 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -346,5 +346,6 @@ CONFIG_CRYPTO_DEV_VMX=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_PRINTK_TIME=y
diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 7e68cb222c7b..4599fc7be285 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -61,6 +61,7 @@ CONFIG_ELECTRA_CF=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_OPROFILE=m
 CONFIG_KPROBES=y
diff --git a/arch/powerpc/configs/pseries_defconfig 
b/arch/powerpc/configs/pseries_defconfig
index 6b68109e248f..4cad3901b5de 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -321,5 +321,6 @@ CONFIG_CRYPTO_DEV_VMX=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_PRINTK_TIME=y
diff --git a/arch/s390/configs/debug_defconfig 
b/arch/s390/configs/debug_defconfig
index 0c86ba19fa2b..6ec6e69630d1 100644
--- a/arch/s390/configs/debug_defconfig
+++ b/arch/s390/configs/debug_defconfig
@@ -57,6 +57,7 @@ CONFIG_PROTECTED_VIRTUALIZATION_GUEST=y
 CONFIG_CMM=m
 CONFIG_APPLDATA_BASE=y
 CONFIG_KVM=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_VHOST_VSOCK=m
 CONFIG_OPROFILE=m
diff --git a/arch/s390/configs/defconfig b/arch/s390/configs/defconfig
index 6b27d861a9a3..d1b3bf83d687 100644
--- a/arch/s390/configs/defconfig
+++ b/arch/s390/configs/defconfig
@@ -57,6 +57,7 @@ CONFIG_PROTECTED_VIRTUALIZATION_GUEST=y
 CONFIG_CMM=m
 CONFIG_APPLDATA_BASE=y
 CONFIG_KVM=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_VHOST_VSOCK=m
 CONFIG_OPROFILE=m
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index e79cbbdfea45..29f171a53d8a 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -12,23 +12,19 @@ config VHOST_RING
  This option is selected by any driver which needs to access
  the host side of a virtio ring.
 
-config VHOST
-   tristate
+menuconfig VHOST
+   tristate "Vhost Devices"
+   depends on EVENTFD
select VHOST_IOTLB
help
- This option is selected by any driver which needs to access
- the core of vhost.
+ Enable option to support host kernel or hardware accelerator
+ for virtio device.
 
-menuconfig VHOST_MENU
-   bool "VHOST drivers"
-   default y
-
-if VHOST_MENU
+if VHOST
 
 config VHOST_NET
tristate "Host kernel accelerator for virtio net"
-   depends on NET && EVENTFD && (TUN || !TUN) && (TAP || !TAP)
-   select VHOST
+   depends on NET && (TUN || !TUN) && (TAP || !TAP)
---help---
  This kernel module can be loaded in host kernel to accelerate
  guest networking with virtio_net. Not to be confused with

Re: [PATCH] vhost: do not enable VHOST_MENU by default

2020-04-14 Thread Jason Wang




On 2020/4/15 上午5:15, kbuild test robot wrote:

Hi Jason,

I love your patch! Yet something to improve:

[auto build test ERROR on vhost/linux-next]
[also build test ERROR on next-20200414]
[cannot apply to powerpc/next s390/features v5.7-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Jason-Wang/vhost-do-not-enable-VHOST_MENU-by-default/20200414-110807
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: ia64-randconfig-a001-20200415 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
 wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
 chmod +x ~/bin/make.cross
 # save the attached .config to linux build tree
 GCC_VERSION=9.3.0 make.cross ARCH=ia64

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 

All error/warnings (new ones prefixed by >>):

drivers/vhost/vhost.c: In function 'vhost_vring_ioctl':

drivers/vhost/vhost.c:1577:33: error: implicit declaration of function 
'eventfd_fget'; did you mean 'eventfd_signal'? 
[-Werror=implicit-function-declaration]

 1577 |   eventfp = f.fd == -1 ? NULL : eventfd_fget(f.fd);
  | ^~~~
  | eventfd_signal

drivers/vhost/vhost.c:1577:31: warning: pointer/integer type mismatch in 
conditional expression



Forget to make VHOST depend on EVENTFD.

Will send v2.

Thanks



 1577 |   eventfp = f.fd == -1 ? NULL : eventfd_fget(f.fd);
  |   ^
cc1: some warnings being treated as errors

vim +1577 drivers/vhost/vhost.c

feebcaeac79ad8 Jason Wang 2019-05-24  1493
feebcaeac79ad8 Jason Wang 2019-05-24  1494  static long 
vhost_vring_set_num_addr(struct vhost_dev *d,
feebcaeac79ad8 Jason Wang 2019-05-24  1495  
 struct vhost_virtqueue *vq,
feebcaeac79ad8 Jason Wang 2019-05-24  1496  
 unsigned int ioctl,
feebcaeac79ad8 Jason Wang 2019-05-24  1497  
 void __user *argp)
feebcaeac79ad8 Jason Wang 2019-05-24  1498  {
feebcaeac79ad8 Jason Wang 2019-05-24  1499  long r;
feebcaeac79ad8 Jason Wang 2019-05-24  1500
feebcaeac79ad8 Jason Wang 2019-05-24  1501  mutex_lock(>mutex);
feebcaeac79ad8 Jason Wang 2019-05-24  1502
feebcaeac79ad8 Jason Wang 2019-05-24  1503  switch (ioctl) {
feebcaeac79ad8 Jason Wang 2019-05-24  1504  case 
VHOST_SET_VRING_NUM:
feebcaeac79ad8 Jason Wang 2019-05-24  1505  r = 
vhost_vring_set_num(d, vq, argp);
feebcaeac79ad8 Jason Wang 2019-05-24  1506  break;
feebcaeac79ad8 Jason Wang 2019-05-24  1507  case 
VHOST_SET_VRING_ADDR:
feebcaeac79ad8 Jason Wang 2019-05-24  1508  r = 
vhost_vring_set_addr(d, vq, argp);
feebcaeac79ad8 Jason Wang 2019-05-24  1509  break;
feebcaeac79ad8 Jason Wang 2019-05-24  1510  default:
feebcaeac79ad8 Jason Wang 2019-05-24  1511  BUG();
feebcaeac79ad8 Jason Wang 2019-05-24  1512  }
feebcaeac79ad8 Jason Wang 2019-05-24  1513
feebcaeac79ad8 Jason Wang 2019-05-24  1514  
mutex_unlock(>mutex);
feebcaeac79ad8 Jason Wang 2019-05-24  1515
feebcaeac79ad8 Jason Wang 2019-05-24  1516  return r;
feebcaeac79ad8 Jason Wang 2019-05-24  1517  }
26b36604523f4a Sonny Rao  2018-03-14  1518  long 
vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp)
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1519  {
cecb46f194460d Al Viro2012-08-27  1520  struct file *eventfp, 
*filep = NULL;
cecb46f194460d Al Viro2012-08-27  1521  bool pollstart = false, 
pollstop = false;
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1522  struct eventfd_ctx *ctx 
= NULL;
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1523  u32 __user *idxp = argp;
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1524  struct vhost_virtqueue 
*vq;
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1525  struct 
vhost_vring_state s;
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1526  struct vhost_vring_file 
f;
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1527  u32 idx;
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1528  long r;
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1529
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1530  r = get_user(idx, idxp);
3a4d5c94e95935 Michael S. Tsirkin 2010-01-14  1531  if (r < 0)
3a4d5c94e95935 Michael S. Tsirkin 2

Re: [PATCH] vhost: do not enable VHOST_MENU by default

2020-04-14 Thread Jason Wang




On 2020/4/14 下午3:26, Christian Borntraeger wrote:

On 14.04.20 04:44, Jason Wang wrote:

We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
without the caring of CONFIG_VHOST.

But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
for the ones that doesn't want vhost. So it actually shifts the
burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
not set". So this patch tries to enable CONFIG_VHOST explicitly in
defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.

Cc: Thomas Bogendoerfer
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger

Fine with me.
s390 part

Acked-by: Christian Borntraeger

  That was my first approach to get things fixed before I reported
this to you.



Exactly.

Thanks

[PATCH] vhost: do not enable VHOST_MENU by default

2020-04-13 Thread Jason Wang

We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
without the caring of CONFIG_VHOST.

But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
for the ones that doesn't want vhost. So it actually shifts the
burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
not set". So this patch tries to enable CONFIG_VHOST explicitly in
defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.

Cc: Thomas Bogendoerfer 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Reported-by: Geert Uytterhoeven 
Signed-off-by: Jason Wang 
---
 arch/mips/configs/malta_kvm_defconfig  |  1 +
 arch/powerpc/configs/powernv_defconfig |  1 +
 arch/powerpc/configs/ppc64_defconfig   |  1 +
 arch/powerpc/configs/pseries_defconfig |  1 +
 arch/s390/configs/debug_defconfig  |  1 +
 arch/s390/configs/defconfig|  1 +
 drivers/vhost/Kconfig  | 18 +-
 7 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/mips/configs/malta_kvm_defconfig 
b/arch/mips/configs/malta_kvm_defconfig
index 8ef612552a19..06f0c7a0ca87 100644
--- a/arch/mips/configs/malta_kvm_defconfig
+++ b/arch/mips/configs/malta_kvm_defconfig
@@ -18,6 +18,7 @@ CONFIG_PCI=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM=m
 CONFIG_KVM_MIPS_DEBUG_COP0_COUNTERS=y
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
diff --git a/arch/powerpc/configs/powernv_defconfig 
b/arch/powerpc/configs/powernv_defconfig
index 71749377d164..404245b4594d 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -346,5 +346,6 @@ CONFIG_CRYPTO_DEV_VMX=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_PRINTK_TIME=y
diff --git a/arch/powerpc/configs/ppc64_defconfig 
b/arch/powerpc/configs/ppc64_defconfig
index 7e68cb222c7b..4599fc7be285 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -61,6 +61,7 @@ CONFIG_ELECTRA_CF=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_OPROFILE=m
 CONFIG_KPROBES=y
diff --git a/arch/powerpc/configs/pseries_defconfig 
b/arch/powerpc/configs/pseries_defconfig
index 6b68109e248f..4cad3901b5de 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -321,5 +321,6 @@ CONFIG_CRYPTO_DEV_VMX=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_PRINTK_TIME=y
diff --git a/arch/s390/configs/debug_defconfig 
b/arch/s390/configs/debug_defconfig
index 0c86ba19fa2b..6ec6e69630d1 100644
--- a/arch/s390/configs/debug_defconfig
+++ b/arch/s390/configs/debug_defconfig
@@ -57,6 +57,7 @@ CONFIG_PROTECTED_VIRTUALIZATION_GUEST=y
 CONFIG_CMM=m
 CONFIG_APPLDATA_BASE=y
 CONFIG_KVM=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_VHOST_VSOCK=m
 CONFIG_OPROFILE=m
diff --git a/arch/s390/configs/defconfig b/arch/s390/configs/defconfig
index 6b27d861a9a3..d1b3bf83d687 100644
--- a/arch/s390/configs/defconfig
+++ b/arch/s390/configs/defconfig
@@ -57,6 +57,7 @@ CONFIG_PROTECTED_VIRTUALIZATION_GUEST=y
 CONFIG_CMM=m
 CONFIG_APPLDATA_BASE=y
 CONFIG_KVM=m
+CONFIG_VHOST=m
 CONFIG_VHOST_NET=m
 CONFIG_VHOST_VSOCK=m
 CONFIG_OPROFILE=m
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index e79cbbdfea45..14d296dc18cd 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -12,23 +12,18 @@ config VHOST_RING
  This option is selected by any driver which needs to access
  the host side of a virtio ring.
 
-config VHOST
-   tristate
+menuconfig VHOST
+   tristate "Vhost Devices"
select VHOST_IOTLB
help
- This option is selected by any driver which needs to access
- the core of vhost.
-
-menuconfig VHOST_MENU
-   bool "VHOST drivers"
-   default y
+ Enable option to support host kernel or hardware accelerator
+ for virtio device.
 
-if VHOST_MENU
+if VHOST
 
 config VHOST_NET
tristate "Host kernel accelerator for virtio net"
depends on NET && EVENTFD && (TUN || !TUN) && (TAP || !TAP)
-   select VHOST
---help---
  This kernel module can be loaded in host kernel to accelerate
  guest networking with virtio_net. Not to be confused with virtio_net
@@ -40,7 +35,6 @@ config VHOST_NET
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
depends on TARGET_CORE && EVENTFD
-   select VHOST
default n
---help---

Re: [PATCH 2/2] virtio_ring: Use DMA API if memory is encrypted

2019-10-16 Thread Jason Wang




On 2019/10/15 下午3:35, Christoph Hellwig wrote:

On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:

From: Thiago Jung Bauermann 

Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
be set by both device and guest driver. However, as a hack, when DMA API
returns physical addresses, guest driver can use the DMA API; even though
device does not set VIRTIO_F_IOMMU_PLATFORM and just uses physical
addresses.

Sorry, but this is a complete bullshit hack.  Driver must always use
the DMA API if they do DMA, and if virtio devices use physical addresses
that needs to be returned through the platform firmware interfaces for
the dma setup.  If you don't do that yet (which based on previous
informations you don't), you need to fix it, and we can then quirk
old implementations that already are out in the field.

In other words: we finally need to fix that virtio mess and not pile
hacks on top of hacks.



I agree, the only reason for IOMMU_PLATFORM is to make sure guest works 
for some old and buggy qemu when vIOMMU is enabled which seems useless 
(note we don't even support vIOMMU migration in that case).


Thanks

Re: [PATCH net] vhost: flush dcache page when logging dirty pages

2019-04-10 Thread Jason Wang




On 2019/4/9 下午9:14, Michael S. Tsirkin wrote:

On Tue, Apr 09, 2019 at 12:16:47PM +0800, Jason Wang wrote:

We set dirty bit through setting up kmaps and access them through
kernel virtual address, this may result alias in virtually tagged
caches that require a dcache flush afterwards.

Cc: Christoph Hellwig 
Cc: James Bottomley 
Cc: Andrea Arcangeli 
Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server")

This is like saying "everyone with vhost needs this".
In practice only might affect some architectures.



For the archs that does need dcache flushing, the function is just a nop.



Which ones?



There're more than 10 archs that have ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 
defined, just cc some maintainers of some more influenced ones.




You want to Cc the relevant maintainers
who understand this...


Signed-off-by: Jason Wang 

I am not sure this is a good idea.
The region in question is supposed to be accessed
by userspace at the same time, through atomic operations.

How do we know userspace didn't access it just before?



get_user_pages() will do both flush_annon_page() to make sure the 
userspace write is visible to kernel.





Is that an issue at all given we use
atomics for access? Documentation/core-api/cachetlb.rst does
not mention atomics.
Which architectures are affected?
Assuming atomics actually do need a flush, then don't we need
a flush in the other direction too? How are atomics
supposed to work at all?



It's the issue of visibility, atomic operation is just one of the 
possible operations. If we can finally makes the write visible to each 
other, there will be no issue.


It looks to me we could still end up alias if userspace is accessing the 
dirty log between get_user_pages_fast() and flush_dcache_page(). But the 
flush_dcache_page() can guarantee what kernel wrote is visible to 
userspace finally though some bits cleared by userspace might still 
there. We may end up with more dirty pages noticed by userspace which 
should be harmless.






I really think we need new APIs along the lines of
set_bit_to_user.



Can we simply do:

get_user()

set bit

put_user()

instead?





---
  drivers/vhost/vhost.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 351af88231ad..34a1cedbc5ba 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1711,6 +1711,7 @@ static int set_bit_to_user(int nr, void __user *addr)
base = kmap_atomic(page);
set_bit(bit, base);
kunmap_atomic(base);
+   flush_dcache_page(page);
set_page_dirty_lock(page);
put_page(page);
return 0;

Ignoring the question of whether this actually helps, I doubt
flush_dcache_page is appropriate here.  Pls take a look at
Documentation/core-api/cachetlb.rst as well as the actual
implementation.

I think you meant flush_kernel_dcache_page, and IIUC it must happen
before kunmap, not after (which you still have the va locked).



Looks like you're right.

Thanks





--
2.19.1

Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

2019-01-29 Thread Jason Wang




On 2019/1/30 上午10:36, Michael S. Tsirkin wrote:

On Wed, Jan 30, 2019 at 10:24:01AM +0800, Jason Wang wrote:

On 2019/1/30 上午3:02, Michael S. Tsirkin wrote:

On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote:

Fixing address of powerpc mailing list.

Thiago Jung Bauermann  writes:


Hello,

With Christoph's rework of the DMA API that recently landed, the patch
below is the only change needed in virtio to make it work in a POWER
secure guest under the ultravisor.

The other change we need (making sure the device's dma_map_ops is NULL
so that the dma-direct/swiotlb code is used) can be made in
powerpc-specific code.

Of course, I also have patches (soon to be posted as RFC) which hook up
 to the powerpc secure guest support code.

What do you think?

  From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001
From: Thiago Jung Bauermann 
Date: Thu, 24 Jan 2019 22:08:02 -0200
Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

The host can't access the guest memory when it's encrypted, so using
regular memory pages for the ring isn't an option. Go through the DMA API.

Signed-off-by: Thiago Jung Bauermann 

Well I think this will come back to bite us (witness xen which is now
reworking precisely this path - but at least they aren't to blame, xen
came before ACCESS_PLATFORM).

I also still think the right thing would have been to set
ACCESS_PLATFORM for all systems where device can't access all memory.

But I also think I don't have the energy to argue about power secure
guest anymore.  So be it for power secure guest since the involved
engineers disagree with me.  Hey I've been wrong in the past ;).

But the name "sev_active" makes me scared because at least AMD guys who
were doing the sensible thing and setting ACCESS_PLATFORM (unless I'm
wrong? I reemember distinctly that's so) will likely be affected too.
We don't want that.

So let's find a way to make sure it's just power secure guest for now
pls.

I also think we should add a dma_api near features under virtio_device
such that these hacks can move off data path.


Anyway the current Xen code is conflict with spec which said:

"If this feature bit is set to 0, then the device has same access to memory
addresses supplied to it as the driver has. In particular, the device will
always use physical addresses matching addresses used by the driver
(typically meaning physical addresses used by the CPU) and not translated
further, and can access any address supplied to it by the driver. When
clear, this overrides any platform-specific description of whether device
access is limited or translated in any way, e.g. whether an IOMMU may be
present. "

I wonder how much value that the above description can give us. It's kind of
odd that the behavior of "when the feature is not negotiated" is described
in the spec.

Hmm what's odd about it? We need to describe the behaviour is all cases.



Well, try to limit the behavior of 'legacy' driver is tricky or even 
impossible. Xen is an exact example for this.






Personally I think we can remove the above and then we can
switch to use DMA API unconditionally in guest driver. It may have single
digit regression probably, we can try to overcome it.

Thanks

This has been discussed ad nauseum. virtio is all about compatibility.
Losing a couple of lines of code isn't worth breaking working setups.
People that want "just use DMA API no tricks" now have the option.
Setting a flag in a feature bit map is literally a single line
of code in the hypervisor. So stop pushing for breaking working
legacy setups and just fix it in the right place.



I may miss soemthing, which kind of legacy setup is broken? Do you mean 
using virtio without IOMMU_PLATFORM on platform with IOMMU? We actually 
unbreak this setup.


Thanks





By the way could you please respond about virtio-iommu and
why there's no support for ACCESS_PLATFORM on power?

I have Cc'd you on these discussions.


Thanks!



---
   drivers/virtio/virtio_ring.c | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755484e3..321a27075380 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -259,8 +259,11 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
 * not work without an even larger kludge.  Instead, enable
 * the DMA API if we're a Xen guest, which at least allows
 * all of the sensible Xen configurations to work correctly.
+*
+* Also, if guest memory is encrypted the host can't access
+* it directly. In this case, we'll need to use the DMA API.
 */
-   if (xen_domain())
+   if (xen_domain() || sev_active())
return true;

return false;

--
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

2019-01-29 Thread Jason Wang




On 2019/1/30 上午3:02, Michael S. Tsirkin wrote:

On Tue, Jan 29, 2019 at 03:42:44PM -0200, Thiago Jung Bauermann wrote:

Fixing address of powerpc mailing list.

Thiago Jung Bauermann  writes:


Hello,

With Christoph's rework of the DMA API that recently landed, the patch
below is the only change needed in virtio to make it work in a POWER
secure guest under the ultravisor.

The other change we need (making sure the device's dma_map_ops is NULL
so that the dma-direct/swiotlb code is used) can be made in
powerpc-specific code.

Of course, I also have patches (soon to be posted as RFC) which hook up
 to the powerpc secure guest support code.

What do you think?

 From d0629a36a75c678b4a72b853f8f7f8c17eedd6b3 Mon Sep 17 00:00:00 2001
From: Thiago Jung Bauermann 
Date: Thu, 24 Jan 2019 22:08:02 -0200
Subject: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

The host can't access the guest memory when it's encrypted, so using
regular memory pages for the ring isn't an option. Go through the DMA API.

Signed-off-by: Thiago Jung Bauermann 

Well I think this will come back to bite us (witness xen which is now
reworking precisely this path - but at least they aren't to blame, xen
came before ACCESS_PLATFORM).

I also still think the right thing would have been to set
ACCESS_PLATFORM for all systems where device can't access all memory.

But I also think I don't have the energy to argue about power secure
guest anymore.  So be it for power secure guest since the involved
engineers disagree with me.  Hey I've been wrong in the past ;).

But the name "sev_active" makes me scared because at least AMD guys who
were doing the sensible thing and setting ACCESS_PLATFORM (unless I'm
wrong? I reemember distinctly that's so) will likely be affected too.
We don't want that.

So let's find a way to make sure it's just power secure guest for now
pls.

I also think we should add a dma_api near features under virtio_device
such that these hacks can move off data path.



Anyway the current Xen code is conflict with spec which said:

"If this feature bit is set to 0, then the device has same access to 
memory addresses supplied to it as the driver has. In particular, the 
device will always use physical addresses matching addresses used by the 
driver (typically meaning physical addresses used by the CPU) and not 
translated further, and can access any address supplied to it by the 
driver. When clear, this overrides any platform-specific description of 
whether device access is limited or translated in any way, e.g. whether 
an IOMMU may be present. "


I wonder how much value that the above description can give us. It's 
kind of odd that the behavior of "when the feature is not negotiated" is 
described in the spec. Personally I think we can remove the above and 
then we can switch to use DMA API unconditionally in guest driver. It 
may have single digit regression probably, we can try to overcome it.


Thanks




By the way could you please respond about virtio-iommu and
why there's no support for ACCESS_PLATFORM on power?

I have Cc'd you on these discussions.


Thanks!



---
  drivers/virtio/virtio_ring.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755484e3..321a27075380 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -259,8 +259,11 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
 * not work without an even larger kludge.  Instead, enable
 * the DMA API if we're a Xen guest, which at least allows
 * all of the sensible Xen configurations to work correctly.
+*
+* Also, if guest memory is encrypted the host can't access
+* it directly. In this case, we'll need to use the DMA API.
 */
-   if (xen_domain())
+   if (xen_domain() || sev_active())
return true;

return false;


--
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-08-02 Thread Jason Wang





On 2018年08月03日 04:55, Michael S. Tsirkin wrote:

On Fri, Jul 20, 2018 at 09:29:37AM +0530, Anshuman Khandual wrote:

This patch series is the follow up on the discussions we had before about
the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation
for virito devices (https://patchwork.kernel.org/patch/10417371/). There
were suggestions about doing away with two different paths of transactions
with the host/QEMU, first being the direct GPA and the other being the DMA
API based translations.

First patch attempts to create a direct GPA mapping based DMA operations
structure called 'virtio_direct_dma_ops' with exact same implementation
of the direct GPA path which virtio core currently has but just wrapped in
a DMA API format. Virtio core must use 'virtio_direct_dma_ops' instead of
the arch default in absence of VIRTIO_F_IOMMU_PLATFORM flag to preserve the
existing semantics. The second patch does exactly that inside the function
virtio_finalize_features(). The third patch removes the default direct GPA
path from virtio core forcing it to use DMA API callbacks for all devices.
Now with that change, every device must have a DMA operations structure
associated with it. The fourth patch adds an additional hook which gives
the platform an opportunity to do yet another override if required. This
platform hook can be used on POWER Ultravisor based protected guests to
load up SWIOTLB DMA callbacks to do the required (as discussed previously
in the above mentioned thread how host is allowed to access only parts of
the guest GPA range) bounce buffering into the shared memory for all I/O
scatter gather buffers to be consumed on the host side.

Please go through these patches and review whether this approach broadly
makes sense. I will appreciate suggestions, inputs, comments regarding
the patches or the approach in general. Thank you.

Jason did some work on profiling this. Unfortunately he reports
about 4% extra overhead from this switch on x86 with no vIOMMU.


The test is rather simple, just run pktgen (pktgen_sample01_simple.sh) 
in guest and measure PPS on tap on host.


Thanks



I expect he's writing up the data in more detail, but
just wanted to let you know this would be one more
thing to debug before we can just switch to DMA APIs.



Anshuman Khandual (4):
   virtio: Define virtio_direct_dma_ops structure
   virtio: Override device's DMA OPS with virtio_direct_dma_ops selectively
   virtio: Force virtio core to use DMA API callbacks for all virtio devices
   virtio: Add platform specific DMA API translation for virito devices

  arch/powerpc/include/asm/dma-mapping.h |  6 +++
  arch/powerpc/platforms/pseries/iommu.c |  6 +++
  drivers/virtio/virtio.c| 72 ++
  drivers/virtio/virtio_pci_common.h |  3 ++
  drivers/virtio/virtio_ring.c   | 65 +-
  5 files changed, 89 insertions(+), 63 deletions(-)

--
2.9.3

39 matches

Mail list logo