Re: [PATCH] virtio: a new vcpu watchdog driver

[Randy Dunlap]

Hi--

On 7/30/23 18:25, zhanghao1 wrote:
> A new virtio pci driver is added for listening to vcpus
> inside guest. Each vcpu creates a corresponding thread to
> periodically send data to qemu's back-end watchdog device.
> If a vCPU is in the stall state, data cannot be sent to
> back-end virtio device. As a result, the back-end device
> can detect that the guest is in the stall state.
> 
> The driver is mainly used with the back-end watchdog device of qemu.
> 
> The qemu backend watchdog device is implemented as follow:
> https://lore.kernel.org/qemu-devel/20230705081813.411526-1-zhangh...@kylinos.cn/
> 
> Signed-off-by: zhanghao1 
> ---
>  drivers/virtio/Kconfig  |   9 +
>  drivers/virtio/Makefile |   1 +
>  drivers/virtio/virtio_vcpu_stall_detector.c | 299 
>  3 files changed, 309 insertions(+)
>  create mode 100644 drivers/virtio/virtio_vcpu_stall_detector.c
> 
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 0a53a61231c2..869323e345a1 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -173,4 +173,13 @@ config VIRTIO_DMA_SHARED_BUFFER
>This option adds a flavor of dma buffers that are backed by
>virtio resources.
>  
> +config VIRTIO_VCPU_WATCHDOG
> + tristate "Virtio vcpu watchdog driver"
> + depends on VIRTIO_PCI
> + help
> +  When this driver is bound inside a KVM guest, it will
> +  periodically "pet" an PCI virtio watchdog device from each vCPU

a PCI

> +  and allow the host to detect vCPU stalls.
> +
> +  If you do not intend to run this kernel as a guest, say N.

Kconfig help text should be indented with one tab + 2 spaces
according to coding-style.rst.

>  endif # VIRTIO_MENU
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index 8e98d24917cc..c7341f078a34 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
>  obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o
>  obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o
>  obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
> +obj-$(CONFIG_VIRTIO_VCPU_WATCHDOG) += virtio_vcpu_stall_detector.o
> diff --git a/drivers/virtio/virtio_vcpu_stall_detector.c 
> b/drivers/virtio/virtio_vcpu_stall_detector.c
> new file mode 100644
> index ..58344ca528be
> --- /dev/null
> +++ b/drivers/virtio/virtio_vcpu_stall_detector.c
> @@ -0,0 +1,299 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// VCPU stall detector.
> +// Copyright (C) Kylin Software, 2023
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define VCPU_STALL_REG_STATUS(0x00)
> +#define VCPU_STALL_REG_LOAD_CNT  (0x04)
> +#define VCPU_STALL_REG_CURRENT_CNT   (0x08)
> +#define VCPU_STALL_REG_CLOCK_FREQ_HZ (0x0C)
> +#define VCPU_STALL_REG_LEN   (0x10)
> +#define VCPU_STALL_REG_TIMEOUT_SEC   (0x14)
> +
> +#define VCPU_STALL_DEFAULT_CLOCK_HZ  (10)
> +#define VCPU_STALL_MAX_CLOCK_HZ  (100)
> +#define VCPU_STALL_DEFAULT_TIMEOUT_SEC   (8)
> +#define VCPU_STALL_MAX_TIMEOUT_SEC   (600)
> +
> +struct vcpu_stall_detect_config {
> + u32 clock_freq_hz;
> + u32 stall_timeout_sec;
> +
> + enum cpuhp_state hp_online;
> +};
> +
> +struct vcpu_stall_priv {
> + struct hrtimer vcpu_hrtimer;
> + struct virtio_device *vdev;
> + u32 cpu_id;
> +};
> +
> +struct vcpu_stall {
> + struct vcpu_stall_priv *priv;
> + struct virtqueue *vq;
> + spinlock_t lock;
> + struct pet_event {
> + u32 cpu_id;
> + bool is_initialized;
> + u32 ticks;
> + } pet_event;
> +};
> +
> +static const struct virtio_device_id vcpu_stall_id_table[] = {
> + { VIRTIO_ID_WATCHDOG, VIRTIO_DEV_ANY_ID },
> + { 0, },
> +};
> +
> +/* The vcpu stall configuration structure which applies to all the CPUs */
> +static struct vcpu_stall_detect_config vcpu_stall_config;
> +static struct vcpu_stall *vcpu_stall;
> +
> +static struct vcpu_stall_priv __percpu *vcpu_stall_detectors;
> +
> +static enum hrtimer_restart
> +vcpu_stall_detect_timer_fn(struct hrtimer *hrtimer)

One line instead of the 2 lines above.

> +{

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH virtio] pds_vdpa: protect Makefile from unconfigured debugfs

[Randy Dunlap]

On 7/6/23 16:17, Shannon Nelson wrote:
> debugfs.h protects itself from an undefined DEBUG_FS, so it is
> not necessary to check it in the driver code or the Makefile.
> The driver code had been updated for this, but the Makefile had
> missed the update.
> 
> Link: 
> https://lore.kernel.org/linux-next/fec68c3c-8249-7af4-5390-0495386a7...@infradead.org/
> Fixes: a16291b5bcbb ("pds_vdpa: Add new vDPA driver for AMD/Pensando DSC")
> Signed-off-by: Shannon Nelson 

Reviewed-by: Randy Dunlap 
Tested-by: Randy Dunlap  # build-tested

Thanks.

> ---
>  drivers/vdpa/pds/Makefile | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/vdpa/pds/Makefile b/drivers/vdpa/pds/Makefile
> index 2e22418e3ab3..c2d314d4614d 100644
> --- a/drivers/vdpa/pds/Makefile
> +++ b/drivers/vdpa/pds/Makefile
> @@ -5,6 +5,5 @@ obj-$(CONFIG_PDS_VDPA) := pds_vdpa.o
>  
>  pds_vdpa-y := aux_drv.o \
> cmds.o \
> +   debugfs.o \
> vdpa_dev.o
> -
> -pds_vdpa-$(CONFIG_DEBUG_FS) += debugfs.o

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Jul 6 [drivers/vdpa/pds/pds_vdpa.ko]

[Randy Dunlap]

On 7/5/23 18:57, Stephen Rothwell wrote:
> Hi all,
> 
> Please do *not* add any v6.6 related stuff to your linux-next included
> branches until after v6.5-rc1 has been released.
> 
> Changes since 20230705:
> 

On loongarch, when DEBUG_FS is not set:

ERROR: modpost: "pds_vdpa_debugfs_del_vdpadev" [drivers/vdpa/pds/pds_vdpa.ko] 
undefined!
ERROR: modpost: "pds_vdpa_debugfs_add_vdpadev" [drivers/vdpa/pds/pds_vdpa.ko] 
undefined!
ERROR: modpost: "pds_vdpa_debugfs_reset_vdpadev" [drivers/vdpa/pds/pds_vdpa.ko] 
undefined!
ERROR: modpost: "pds_vdpa_debugfs_create" [drivers/vdpa/pds/pds_vdpa.ko] 
undefined!
ERROR: modpost: "pds_vdpa_debugfs_add_ident" [drivers/vdpa/pds/pds_vdpa.ko] 
undefined!
ERROR: modpost: "pds_vdpa_debugfs_destroy" [drivers/vdpa/pds/pds_vdpa.ko] 
undefined!
ERROR: modpost: "pds_vdpa_debugfs_add_pcidev" [drivers/vdpa/pds/pds_vdpa.ko] 
undefined!



Full randconfig file is attached.

-- 
~Randy

config-r2589.gz
Description: application/gzip
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH] Documentation: virt: clean up paravirt_ops doc.

[Randy Dunlap]

Clarify language. Clean up grammar. Hyphenate some words.

Change "low-ops" to "low-level" since "low-ops" isn't defined or even
mentioned anywhere else in the kernel source tree.

Signed-off-by: Randy Dunlap 
Cc: Juergen Gross 
Cc: Ajay Kaher 
Cc: Alexey Makhalov 
Cc: VMware PV-Drivers Reviewers 
Cc: virtualization@lists.linux-foundation.org
Cc: x...@kernel.org
Cc: Paolo Bonzini 
Cc: "Luke Nowakowski-Krijger" 
Cc: Luis Chamberlain 
---
 Documentation/virt/paravirt_ops.rst |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff -- a/Documentation/virt/paravirt_ops.rst 
b/Documentation/virt/paravirt_ops.rst
--- a/Documentation/virt/paravirt_ops.rst
+++ b/Documentation/virt/paravirt_ops.rst
@@ -5,31 +5,31 @@ Paravirt_ops
 
 
 Linux provides support for different hypervisor virtualization technologies.
-Historically different binary kernels would be required in order to support
-different hypervisors, this restriction was removed with pv_ops.
+Historically, different binary kernels would be required in order to support
+different hypervisors; this restriction was removed with pv_ops.
 Linux pv_ops is a virtualization API which enables support for different
 hypervisors. It allows each hypervisor to override critical operations and
 allows a single kernel binary to run on all supported execution environments
 including native machine -- without any hypervisors.
 
 pv_ops provides a set of function pointers which represent operations
-corresponding to low level critical instructions and high level
-functionalities in various areas. pv-ops allows for optimizations at run
-time by enabling binary patching of the low-ops critical operations
+corresponding to low-level critical instructions and high-level
+functionalities in various areas. pv_ops allows for optimizations at run
+time by enabling binary patching of the low-level critical operations
 at boot time.
 
 pv_ops operations are classified into three categories:
 
 - simple indirect call
-   These operations correspond to high level functionality where it is
+   These operations correspond to high-level functionality where it is
known that the overhead of indirect call isn't very important.
 
 - indirect call which allows optimization with binary patch
-   Usually these operations correspond to low level critical instructions. They
+   Usually these operations correspond to low-level critical instructions. They
are called frequently and are performance critical. The overhead is
very important.
 
 - a set of macros for hand written assembly code
Hand written assembly codes (.S files) also need paravirtualization
-   because they include sensitive instructions or some of code paths in
+   because they include sensitive instructions or some code paths in
them are very performance critical.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 4/9] netfilter: h323: eliminate anonymous module_init & module_exit

[Randy Dunlap]

On 3/17/22 08:49, Pablo Neira Ayuso wrote:
> On Wed, Mar 16, 2022 at 12:20:05PM -0700, Randy Dunlap wrote:
>> Eliminate anonymous module_init() and module_exit(), which can lead to
>> confusion or ambiguity when reading System.map, crashes/oops/bugs,
>> or an initcall_debug log.
>>
>> Give each of these init and exit functions unique driver-specific
>> names to eliminate the anonymous names.
>>
>> Example 1: (System.map)
>>  832fc78c t init
>>  832fc79e t init
>>  832fc8f8 t init
>>
>> Example 2: (initcall_debug log)
>>  calling  init+0x0/0x12 @ 1
>>  initcall init+0x0/0x12 returned 0 after 15 usecs
>>  calling  init+0x0/0x60 @ 1
>>  initcall init+0x0/0x60 returned 0 after 2 usecs
>>  calling  init+0x0/0x9a @ 1
>>  initcall init+0x0/0x9a returned 0 after 74 usecs
> 
> LGTM.
> 
> Should I route this through the netfilter tree?

Yes, please.
Thanks.

> 
>> Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper 
>> port")
>> Signed-off-by: Randy Dunlap 
>> Cc: Pablo Neira Ayuso 
>> Cc: Jozsef Kadlecsik 
>> Cc: Florian Westphal 
>> Cc: netfilter-de...@vger.kernel.org
>> Cc: coret...@netfilter.org
>> Cc: "David S. Miller" 
>> Cc: Jakub Kicinski 
>> Cc: net...@vger.kernel.org
>> ---
>>  net/ipv4/netfilter/nf_nat_h323.c |8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> --- lnx-517-rc8.orig/net/ipv4/netfilter/nf_nat_h323.c
>> +++ lnx-517-rc8/net/ipv4/netfilter/nf_nat_h323.c
>> @@ -580,7 +580,7 @@ static struct nf_ct_helper_expectfn call
>>  };
>>  
>>  
>> //
>> -static int __init init(void)
>> +static int __init nf_nat_h323_init(void)
>>  {
>>  BUG_ON(set_h245_addr_hook != NULL);
>>  BUG_ON(set_h225_addr_hook != NULL);
>> @@ -607,7 +607,7 @@ static int __init init(void)
>>  }
>>  
>>  
>> //
>> -static void __exit fini(void)
>> +static void __exit nf_nat_h323_fini(void)
>>  {
>>  RCU_INIT_POINTER(set_h245_addr_hook, NULL);
>>  RCU_INIT_POINTER(set_h225_addr_hook, NULL);
>> @@ -624,8 +624,8 @@ static void __exit fini(void)
>>  }
>>  
>>  
>> //
>> -module_init(init);
>> -module_exit(fini);
>> +module_init(nf_nat_h323_init);
>> +module_exit(nf_nat_h323_fini);
>>  
>>  MODULE_AUTHOR("Jing Min Zhao ");
>>  MODULE_DESCRIPTION("H.323 NAT helper");

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 2/9] virtio_console: eliminate anonymous module_init & module_exit

[Randy Dunlap]

On 3/17/22 08:47, Amit Shah wrote:
> On Wed, 2022-03-16 at 12:20 -0700, Randy Dunlap wrote:
>> Eliminate anonymous module_init() and module_exit(), which can lead to
>> confusion or ambiguity when reading System.map, crashes/oops/bugs,
>> or an initcall_debug log.
>>
>> Give each of these init and exit functions unique driver-specific
>> names to eliminate the anonymous names.
>>
>> Example 1: (System.map)
>>  832fc78c t init
>>  832fc79e t init
>>  832fc8f8 t init
>>
>> Example 2: (initcall_debug log)
>>  calling  init+0x0/0x12 @ 1
>>  initcall init+0x0/0x12 returned 0 after 15 usecs
>>  calling  init+0x0/0x60 @ 1
>>  initcall init+0x0/0x60 returned 0 after 2 usecs
>>  calling  init+0x0/0x9a @ 1
>>  initcall init+0x0/0x9a returned 0 after 74 usecs
>>
>> Fixes: 31610434bc35 ("Virtio console driver")
>> Fixes: 7177876fea83 ("virtio: console: Add ability to remove module")
>> Signed-off-by: Randy Dunlap <
>> rdun...@infradead.org
>>>
>> Cc: Amit Shah <
>> a...@kernel.org
>>>
>> Cc: 
>> virtualization@lists.linux-foundation.org
>>
>> Cc: Arnd Bergmann <
>> a...@arndb.de
>>>
>> Cc: Greg Kroah-Hartman <
>> gre...@linuxfoundation.org
>>>
>> ---
>>  drivers/char/virtio_console.c |8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> Reviewed-by: Amit Shah 
> 
> I don't think the Fixes-by really applies here, though - we don't
> really want to push this into stable, nor do we want any automated
> tools to pick this up because of that tag..

Yeah, I'm fine with that.

thanks.

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 6/9] usb: gadget: eliminate anonymous module_init & module_exit

[Randy Dunlap]

On 3/16/22 20:29, Ira Weiny wrote:
> On Wed, Mar 16, 2022 at 12:20:07PM -0700, Randy Dunlap wrote:
>> Eliminate anonymous module_init() and module_exit(), which can lead to
>> confusion or ambiguity when reading System.map, crashes/oops/bugs,
>> or an initcall_debug log.
>>
>> Give each of these init and exit functions unique driver-specific
>> names to eliminate the anonymous names.
>>
>> Example 1: (System.map)
>>  832fc78c t init
>>  832fc79e t init
>>  832fc8f8 t init
>>
>> Example 2: (initcall_debug log)
>>  calling  init+0x0/0x12 @ 1
>>  initcall init+0x0/0x12 returned 0 after 15 usecs
>>  calling  init+0x0/0x60 @ 1
>>  initcall init+0x0/0x60 returned 0 after 2 usecs
>>  calling  init+0x0/0x9a @ 1
>>  initcall init+0x0/0x9a returned 0 after 74 usecs
>>
>> Fixes: bd25a14edb75 ("usb: gadget: legacy/serial: allow dynamic removal")
>> Fixes: 7bb5ea54be47 ("usb gadget serial: use composite gadget framework")
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> 
> I continue to be confused about the latest rules for the Fixes tag but this 
> one
> in particular seems completely useless.  This is the 'beginning of time' 
> commit
> by Linus AFAICT.  So do any of these Fixes tags need to be in this series?

I guess it mostly depends on whether they get applied to stable trees, but
it's entirely fine with me if they don't.

{I also corrected Felipe's email address here.}

> Regardless:
> 
> Reviewed-by: Ira Weiny 

Thanks.

> 
>> Signed-off-by: Randy Dunlap 
>> Cc: Felipe Balbi 
>> Cc: Michał Mirosław 
>> Cc: Greg Kroah-Hartman 
>> Cc: Sebastian Andrzej Siewior 
>> Cc: linux-...@vger.kernel.org
>> ---
>>  drivers/usb/gadget/legacy/inode.c  |8 
>>  drivers/usb/gadget/legacy/serial.c |   10 +-
>>  drivers/usb/gadget/udc/dummy_hcd.c |8 
>>  3 files changed, 13 insertions(+), 13 deletions(-)
>>
>> --- lnx-517-rc8.orig/drivers/usb/gadget/legacy/serial.c
>> +++ lnx-517-rc8/drivers/usb/gadget/legacy/serial.c
>> @@ -273,7 +273,7 @@ static struct usb_composite_driver gseri
>>  static int switch_gserial_enable(bool do_enable)
>>  {
>>  if (!serial_config_driver.label)
>> -/* init() was not called, yet */
>> +/* gserial_init() was not called, yet */
>>  return 0;
>>  
>>  if (do_enable)
>> @@ -283,7 +283,7 @@ static int switch_gserial_enable(bool do
>>  return 0;
>>  }
>>  
>> -static int __init init(void)
>> +static int __init gserial_init(void)
>>  {
>>  /* We *could* export two configs; that'd be much cleaner...
>>   * but neither of these product IDs was defined that way.
>> @@ -314,11 +314,11 @@ static int __init init(void)
>>  
>>  return usb_composite_probe(_driver);
>>  }
>> -module_init(init);
>> +module_init(gserial_init);
>>  
>> -static void __exit cleanup(void)
>> +static void __exit gserial_cleanup(void)
>>  {
>>  if (enable)
>>  usb_composite_unregister(_driver);
>>  }
>> -module_exit(cleanup);
>> +module_exit(gserial_cleanup);
>> --- lnx-517-rc8.orig/drivers/usb/gadget/udc/dummy_hcd.c
>> +++ lnx-517-rc8/drivers/usb/gadget/udc/dummy_hcd.c
>> @@ -2765,7 +2765,7 @@ static struct platform_driver dummy_hcd_
>>  static struct platform_device *the_udc_pdev[MAX_NUM_UDC];
>>  static struct platform_device *the_hcd_pdev[MAX_NUM_UDC];
>>  
>> -static int __init init(void)
>> +static int __init dummy_hcd_init(void)
>>  {
>>  int retval = -ENOMEM;
>>  int i;
>> @@ -2887,9 +2887,9 @@ err_alloc_udc:
>>  platform_device_put(the_hcd_pdev[i]);
>>  return retval;
>>  }
>> -module_init(init);
>> +module_init(dummy_hcd_init);
>>  
>> -static void __exit cleanup(void)
>> +static void __exit dummy_hcd_cleanup(void)
>>  {
>>  int i;
>>  
>> @@ -2905,4 +2905,4 @@ static void __exit cleanup(void)
>>  platform_driver_unregister(_udc_driver);
>>  platform_driver_unregister(_hcd_driver);
>>  }
>> -module_exit(cleanup);
>> +module_exit(dummy_hcd_cleanup);
>> --- lnx-517-rc8.orig/drivers/usb/gadget/legacy/inode.c
>> +++ lnx-517-rc8/drivers/usb/gadget/legacy/inode.c
>> @@ -2101,7 +2101,7 @@ MODULE_ALIAS_FS("gadgetfs");
>>  
>>  /*--*/
>>  
>> -static int __init init (void)
>> +static int __init gadgetfs_init (void)
>>  {
>>  int status;
>>  
>> @@ -2111,12 +2111,12 @@ static int __init init (void)
>>  shortname, driver_desc);
>>  return status;
>>  }
>> -module_init (init);
>> +module_init (gadgetfs_init);
>>  
>> -static void __exit cleanup (void)
>> +static void __exit gadgetfs_cleanup (void)
>>  {
>>  pr_debug ("unregister %s\n", shortname);
>>  unregister_filesystem (_type);
>>  }
>> -module_exit (cleanup);
>> +module_exit (gadgetfs_cleanup);
>>  

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 1/9] virtio_blk: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: e467cde23818 ("Block driver using virtio.")
Signed-off-by: Randy Dunlap 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Paolo Bonzini 
Cc: Stefan Hajnoczi 
Cc: virtualization@lists.linux-foundation.org
Cc: Jens Axboe 
Cc: linux-bl...@vger.kernel.org
---
 drivers/block/virtio_blk.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- lnx-517-rc8.orig/drivers/block/virtio_blk.c
+++ lnx-517-rc8/drivers/block/virtio_blk.c
@@ -1058,7 +1058,7 @@ static struct virtio_driver virtio_blk =
 #endif
 };
 
-static int __init init(void)
+static int __init virtio_blk_init(void)
 {
int error;
 
@@ -1084,14 +1084,14 @@ out_destroy_workqueue:
return error;
 }
 
-static void __exit fini(void)
+static void __exit virtio_blk_fini(void)
 {
unregister_virtio_driver(_blk);
unregister_blkdev(major, "virtblk");
destroy_workqueue(virtblk_wq);
 }
-module_init(init);
-module_exit(fini);
+module_init(virtio_blk_init);
+module_exit(virtio_blk_fini);
 
 MODULE_DEVICE_TABLE(virtio, id_table);
 MODULE_DESCRIPTION("Virtio block driver");
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 9/9] testmmiotrace: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: 8b7d89d02ef3 ("x86: mmiotrace - trace memory mapped IO")
Signed-off-by: Randy Dunlap 
Cc: Thomas Gleixner 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Karol Herbst 
Cc: Pekka Paalanen 
Cc: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: nouv...@lists.freedesktop.org
Cc: x...@kernel.org
---
 arch/x86/mm/testmmiotrace.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- lnx-517-rc8.orig/arch/x86/mm/testmmiotrace.c
+++ lnx-517-rc8/arch/x86/mm/testmmiotrace.c
@@ -113,7 +113,7 @@ static void do_test_bulk_ioremapping(voi
synchronize_rcu();
 }
 
-static int __init init(void)
+static int __init testmmiotrace_init(void)
 {
unsigned long size = (read_far) ? (8 << 20) : (16 << 10);
int ret = security_locked_down(LOCKDOWN_MMIOTRACE);
@@ -136,11 +136,11 @@ static int __init init(void)
return 0;
 }
 
-static void __exit cleanup(void)
+static void __exit testmmiotrace_cleanup(void)
 {
pr_debug("unloaded.\n");
 }
 
-module_init(init);
-module_exit(cleanup);
+module_init(testmmiotrace_init);
+module_exit(testmmiotrace_cleanup);
 MODULE_LICENSE("GPL");
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 5/9] virtio-scsi: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: 4fe74b1cb051 ("[SCSI] virtio-scsi: SCSI driver for QEMU based virtual 
machines")
Signed-off-by: Randy Dunlap 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Paolo Bonzini 
Cc: Stefan Hajnoczi 
Cc: "James E.J. Bottomley" 
Cc: "Martin K. Petersen" 
Cc: linux-s...@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
---
 drivers/scsi/virtio_scsi.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- lnx-517-rc8.orig/drivers/scsi/virtio_scsi.c
+++ lnx-517-rc8/drivers/scsi/virtio_scsi.c
@@ -988,7 +988,7 @@ static struct virtio_driver virtio_scsi_
.remove = virtscsi_remove,
 };
 
-static int __init init(void)
+static int __init virtio_scsi_init(void)
 {
int ret = -ENOMEM;
 
@@ -1020,14 +1020,14 @@ error:
return ret;
 }
 
-static void __exit fini(void)
+static void __exit virtio_scsi_fini(void)
 {
unregister_virtio_driver(_scsi_driver);
mempool_destroy(virtscsi_cmd_pool);
kmem_cache_destroy(virtscsi_cmd_cache);
 }
-module_init(init);
-module_exit(fini);
+module_init(virtio_scsi_init);
+module_exit(virtio_scsi_fini);
 
 MODULE_DEVICE_TABLE(virtio, id_table);
 MODULE_DESCRIPTION("Virtio SCSI HBA driver");
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 0/9] treewide: eliminate anonymous module_init & module_exit

[Randy Dunlap]

There are a number of drivers that use "module_init(init)" and
"module_exit(exit)", which are anonymous names and can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init
 832fca05 t init
 832fcbd2 t init
 83328f0e t init
 8332c5b1 t init
 8332d9eb t init
 8332f0aa t init
 83330e25 t init
 833317a5 t init
 8333dd6b t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs
 calling  init+0x0/0x73 @ 1
 initcall init+0x0/0x73 returned 0 after 6 usecs
 calling  init+0x0/0x73 @ 1
 initcall init+0x0/0x73 returned 0 after 4 usecs
 calling  init+0x0/0xf5 @ 1
 initcall init+0x0/0xf5 returned 0 after 27 usecs
 calling  init+0x0/0x7d @ 1
 initcall init+0x0/0x7d returned 0 after 11 usecs
 calling  init+0x0/0xc9 @ 1
 initcall init+0x0/0xc9 returned 0 after 19 usecs
 calling  init+0x0/0x9d @ 1
 initcall init+0x0/0x9d returned 0 after 37 usecs
 calling  init+0x0/0x63f @ 1
 initcall init+0x0/0x63f returned 0 after 411 usecs
 calling  init+0x0/0x171 @ 1
 initcall init+0x0/0x171 returned 0 after 61 usecs
 calling  init+0x0/0xef @ 1
 initcall init+0x0/0xef returned 0 after 3 usecs

Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Paolo Bonzini 
Cc: Stefan Hajnoczi 
Cc: Jens Axboe 
Cc: Amit Shah 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Eli Cohen 
Cc: Saeed Mahameed 
Cc: Leon Romanovsky 
Cc: Pablo Neira Ayuso 
Cc: Jozsef Kadlecsik 
Cc: Florian Westphal 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: "James E.J. Bottomley" 
Cc: "Martin K. Petersen" 
Cc: Felipe Balbi 
Cc: Michał Mirosław 
Cc: Sebastian Andrzej Siewior 
Cc: Krzysztof Opasiak 
Cc: Igor Kotrasinski 
Cc: Valentina Manea 
Cc: Shuah Khan 
Cc: Shuah Khan 
Cc: Jussi Kivilinna 
Cc: Joachim Fritschi 
Cc: Herbert Xu 
Cc: Thomas Gleixner 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Karol Herbst 
Cc: Pekka Paalanen 
Cc: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: netfilter-de...@vger.kernel.org
Cc: coret...@netfilter.org
Cc: net...@vger.kernel.org
Cc: linux-bl...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: nouv...@lists.freedesktop.org
Cc: virtualization@lists.linux-foundation.org
Cc: x...@kernel.org

patches:
 [PATCH 1/9] virtio_blk: eliminate anonymous module_init & module_exit
 [PATCH 2/9] virtio_console: eliminate anonymous module_init & module_exit
 [PATCH 3/9] net: mlx5: eliminate anonymous module_init & module_exit
 [PATCH 4/9] netfilter: h323: eliminate anonymous module_init & module_exit
 [PATCH 5/9] virtio-scsi: eliminate anonymous module_init & module_exit
 [PATCH 6/9] usb: gadget: eliminate anonymous module_init & module_exit
 [PATCH 7/9] usb: usbip: eliminate anonymous module_init & module_exit
 [PATCH 8/9] x86/crypto: eliminate anonymous module_init & module_exit
 [PATCH 9/9] testmmiotrace: eliminate anonymous module_init & module_exit

diffstat:
 arch/x86/crypto/blowfish_glue.c|8 
 arch/x86/crypto/camellia_glue.c|8 
 arch/x86/crypto/serpent_avx2_glue.c|8 
 arch/x86/crypto/twofish_glue.c |8 
 arch/x86/crypto/twofish_glue_3way.c|8 
 arch/x86/mm/testmmiotrace.c|8 
 drivers/block/virtio_blk.c |8 
 drivers/char/virtio_console.c  |8 
 drivers/net/ethernet/mellanox/mlx5/core/main.c |8 
 drivers/scsi/virtio_scsi.c |8 
 drivers/usb/gadget/legacy/inode.c  |8 
 drivers/usb/gadget/legacy/serial.c |   10 +-
 drivers/usb/gadget/udc/dummy_hcd.c |8 
 drivers/usb/usbip/vudc_main.c  |8 
 net/ipv4/netfilter/nf_nat_h323.c   |8 
 15 files changed, 61 insertions(+), 61 deletions(-)
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 8/9] x86/crypto: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: 64b94ceae8c1 ("crypto: blowfish - add x86_64 assembly implementation")
Fixes: 676a38046f4f ("crypto: camellia-x86_64 - module init/exit functions 
should be static")
Fixes: 0b95ec56ae19 ("crypto: camellia - add assembler implementation for 
x86_64")
Fixes: 56d76c96a9f3 ("crypto: serpent - add AVX2/x86_64 assembler 
implementation of serpent cipher")
Fixes: b9f535ffe38f ("[CRYPTO] twofish: i586 assembly version")
Fixes: ff0a70fe0536 ("crypto: twofish-x86_64-3way - module init/exit functions 
should be static")
Fixes: 8280daad436e ("crypto: twofish - add 3-way parallel x86_64 assembler 
implemention")
Signed-off-by: Randy Dunlap 
Cc: Jussi Kivilinna 
Cc: Joachim Fritschi 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: linux-cry...@vger.kernel.org
Cc: x...@kernel.org
---
 arch/x86/crypto/blowfish_glue.c |8 
 arch/x86/crypto/camellia_glue.c |8 
 arch/x86/crypto/serpent_avx2_glue.c |8 
 arch/x86/crypto/twofish_glue.c  |8 
 arch/x86/crypto/twofish_glue_3way.c |8 
 5 files changed, 20 insertions(+), 20 deletions(-)

--- lnx-517-rc8.orig/arch/x86/crypto/blowfish_glue.c
+++ lnx-517-rc8/arch/x86/crypto/blowfish_glue.c
@@ -315,7 +315,7 @@ static int force;
 module_param(force, int, 0);
 MODULE_PARM_DESC(force, "Force module load, ignore CPU blacklist");
 
-static int __init init(void)
+static int __init blowfish_init(void)
 {
int err;
 
@@ -339,15 +339,15 @@ static int __init init(void)
return err;
 }
 
-static void __exit fini(void)
+static void __exit blowfish_fini(void)
 {
crypto_unregister_alg(_cipher_alg);
crypto_unregister_skciphers(bf_skcipher_algs,
ARRAY_SIZE(bf_skcipher_algs));
 }
 
-module_init(init);
-module_exit(fini);
+module_init(blowfish_init);
+module_exit(blowfish_fini);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Blowfish Cipher Algorithm, asm optimized");
--- lnx-517-rc8.orig/arch/x86/crypto/camellia_glue.c
+++ lnx-517-rc8/arch/x86/crypto/camellia_glue.c
@@ -1377,7 +1377,7 @@ static int force;
 module_param(force, int, 0);
 MODULE_PARM_DESC(force, "Force module load, ignore CPU blacklist");
 
-static int __init init(void)
+static int __init camellia_init(void)
 {
int err;
 
@@ -1401,15 +1401,15 @@ static int __init init(void)
return err;
 }
 
-static void __exit fini(void)
+static void __exit camellia_fini(void)
 {
crypto_unregister_alg(_cipher_alg);
crypto_unregister_skciphers(camellia_skcipher_algs,
ARRAY_SIZE(camellia_skcipher_algs));
 }
 
-module_init(init);
-module_exit(fini);
+module_init(camellia_init);
+module_exit(camellia_fini);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Camellia Cipher Algorithm, asm optimized");
--- lnx-517-rc8.orig/arch/x86/crypto/serpent_avx2_glue.c
+++ lnx-517-rc8/arch/x86/crypto/serpent_avx2_glue.c
@@ -96,7 +96,7 @@ static struct skcipher_alg serpent_algs[
 
 static struct simd_skcipher_alg *serpent_simd_algs[ARRAY_SIZE(serpent_algs)];
 
-static int __init init(void)
+static int __init serpent_avx2_init(void)
 {
const char *feature_name;
 
@@ -115,14 +115,14 @@ static int __init init(void)
  serpent_simd_algs);
 }
 
-static void __exit fini(void)
+static void __exit serpent_avx2_fini(void)
 {
simd_unregister_skciphers(serpent_algs, ARRAY_SIZE(serpent_algs),
  serpent_simd_algs);
 }
 
-module_init(init);
-module_exit(fini);
+module_init(serpent_avx2_init);
+module_exit(serpent_avx2_fini);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Serpent Cipher Algorithm, AVX2 optimized");
--- lnx-517-rc8.orig/arch/x86/crypto/twofish_glue.c
+++ lnx-517-rc8/arch/x86/crypto/twofish_glue.c
@@ -81,18 +81,18 @@ static struct crypto_alg alg = {
}
 };
 
-static int __init init(void)
+static int __init twofish_glue_init(void)
 {
return crypto_register_alg();
 }
 
-static void __exit fini(void)
+static void __exit twofish_glue_fini(void)
 {
crypto_unregister_alg();
 }
 
-module_init(init);
-module_exit(fini);
+module_init(twofish_glue_init);
+module_exit(twofish_glue_fini);

[PATCH 6/9] usb: gadget: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: bd25a14edb75 ("usb: gadget: legacy/serial: allow dynamic removal")
Fixes: 7bb5ea54be47 ("usb gadget serial: use composite gadget framework")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Randy Dunlap 
Cc: Felipe Balbi 
Cc: Michał Mirosław 
Cc: Greg Kroah-Hartman 
Cc: Sebastian Andrzej Siewior 
Cc: linux-...@vger.kernel.org
---
 drivers/usb/gadget/legacy/inode.c  |8 
 drivers/usb/gadget/legacy/serial.c |   10 +-
 drivers/usb/gadget/udc/dummy_hcd.c |8 
 3 files changed, 13 insertions(+), 13 deletions(-)

--- lnx-517-rc8.orig/drivers/usb/gadget/legacy/serial.c
+++ lnx-517-rc8/drivers/usb/gadget/legacy/serial.c
@@ -273,7 +273,7 @@ static struct usb_composite_driver gseri
 static int switch_gserial_enable(bool do_enable)
 {
if (!serial_config_driver.label)
-   /* init() was not called, yet */
+   /* gserial_init() was not called, yet */
return 0;
 
if (do_enable)
@@ -283,7 +283,7 @@ static int switch_gserial_enable(bool do
return 0;
 }
 
-static int __init init(void)
+static int __init gserial_init(void)
 {
/* We *could* export two configs; that'd be much cleaner...
 * but neither of these product IDs was defined that way.
@@ -314,11 +314,11 @@ static int __init init(void)
 
return usb_composite_probe(_driver);
 }
-module_init(init);
+module_init(gserial_init);
 
-static void __exit cleanup(void)
+static void __exit gserial_cleanup(void)
 {
if (enable)
usb_composite_unregister(_driver);
 }
-module_exit(cleanup);
+module_exit(gserial_cleanup);
--- lnx-517-rc8.orig/drivers/usb/gadget/udc/dummy_hcd.c
+++ lnx-517-rc8/drivers/usb/gadget/udc/dummy_hcd.c
@@ -2765,7 +2765,7 @@ static struct platform_driver dummy_hcd_
 static struct platform_device *the_udc_pdev[MAX_NUM_UDC];
 static struct platform_device *the_hcd_pdev[MAX_NUM_UDC];
 
-static int __init init(void)
+static int __init dummy_hcd_init(void)
 {
int retval = -ENOMEM;
int i;
@@ -2887,9 +2887,9 @@ err_alloc_udc:
platform_device_put(the_hcd_pdev[i]);
return retval;
 }
-module_init(init);
+module_init(dummy_hcd_init);
 
-static void __exit cleanup(void)
+static void __exit dummy_hcd_cleanup(void)
 {
int i;
 
@@ -2905,4 +2905,4 @@ static void __exit cleanup(void)
platform_driver_unregister(_udc_driver);
platform_driver_unregister(_hcd_driver);
 }
-module_exit(cleanup);
+module_exit(dummy_hcd_cleanup);
--- lnx-517-rc8.orig/drivers/usb/gadget/legacy/inode.c
+++ lnx-517-rc8/drivers/usb/gadget/legacy/inode.c
@@ -2101,7 +2101,7 @@ MODULE_ALIAS_FS("gadgetfs");
 
 /*--*/
 
-static int __init init (void)
+static int __init gadgetfs_init (void)
 {
int status;
 
@@ -2111,12 +2111,12 @@ static int __init init (void)
shortname, driver_desc);
return status;
 }
-module_init (init);
+module_init (gadgetfs_init);
 
-static void __exit cleanup (void)
+static void __exit gadgetfs_cleanup (void)
 {
pr_debug ("unregister %s\n", shortname);
unregister_filesystem (_type);
 }
-module_exit (cleanup);
+module_exit (gadgetfs_cleanup);
 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 4/9] netfilter: h323: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper port")
Signed-off-by: Randy Dunlap 
Cc: Pablo Neira Ayuso 
Cc: Jozsef Kadlecsik 
Cc: Florian Westphal 
Cc: netfilter-de...@vger.kernel.org
Cc: coret...@netfilter.org
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: net...@vger.kernel.org
---
 net/ipv4/netfilter/nf_nat_h323.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- lnx-517-rc8.orig/net/ipv4/netfilter/nf_nat_h323.c
+++ lnx-517-rc8/net/ipv4/netfilter/nf_nat_h323.c
@@ -580,7 +580,7 @@ static struct nf_ct_helper_expectfn call
 };
 
 //
-static int __init init(void)
+static int __init nf_nat_h323_init(void)
 {
BUG_ON(set_h245_addr_hook != NULL);
BUG_ON(set_h225_addr_hook != NULL);
@@ -607,7 +607,7 @@ static int __init init(void)
 }
 
 //
-static void __exit fini(void)
+static void __exit nf_nat_h323_fini(void)
 {
RCU_INIT_POINTER(set_h245_addr_hook, NULL);
RCU_INIT_POINTER(set_h225_addr_hook, NULL);
@@ -624,8 +624,8 @@ static void __exit fini(void)
 }
 
 //
-module_init(init);
-module_exit(fini);
+module_init(nf_nat_h323_init);
+module_exit(nf_nat_h323_fini);
 
 MODULE_AUTHOR("Jing Min Zhao ");
 MODULE_DESCRIPTION("H.323 NAT helper");
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 2/9] virtio_console: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: 31610434bc35 ("Virtio console driver")
Fixes: 7177876fea83 ("virtio: console: Add ability to remove module")
Signed-off-by: Randy Dunlap 
Cc: Amit Shah 
Cc: virtualization@lists.linux-foundation.org
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
---
 drivers/char/virtio_console.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- lnx-517-rc8.orig/drivers/char/virtio_console.c
+++ lnx-517-rc8/drivers/char/virtio_console.c
@@ -2245,7 +2245,7 @@ static struct virtio_driver virtio_rproc
.remove =   virtcons_remove,
 };
 
-static int __init init(void)
+static int __init virtio_console_init(void)
 {
int err;
 
@@ -2280,7 +2280,7 @@ free:
return err;
 }
 
-static void __exit fini(void)
+static void __exit virtio_console_fini(void)
 {
reclaim_dma_bufs();
 
@@ -2290,8 +2290,8 @@ static void __exit fini(void)
class_destroy(pdrvdata.class);
debugfs_remove_recursive(pdrvdata.debugfs_dir);
 }
-module_init(init);
-module_exit(fini);
+module_init(virtio_console_init);
+module_exit(virtio_console_fini);
 
 MODULE_DESCRIPTION("Virtio console driver");
 MODULE_LICENSE("GPL");
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 3/9] net: mlx5: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Randy Dunlap 
Cc: Eli Cohen 
Cc: Saeed Mahameed 
Cc: net...@vger.kernel.org
Cc: Leon Romanovsky 
Cc: linux-r...@vger.kernel.org
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- lnx-517-rc8.orig/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ lnx-517-rc8/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1893,7 +1893,7 @@ static void mlx5_core_verify_params(void
}
 }
 
-static int __init init(void)
+static int __init mlx5_init(void)
 {
int err;
 
@@ -1929,7 +1929,7 @@ err_debug:
return err;
 }
 
-static void __exit cleanup(void)
+static void __exit mlx5_cleanup(void)
 {
mlx5e_cleanup();
mlx5_sf_driver_unregister();
@@ -1937,5 +1937,5 @@ static void __exit cleanup(void)
mlx5_unregister_debugfs();
 }
 
-module_init(init);
-module_exit(cleanup);
+module_init(mlx5_init);
+module_exit(mlx5_cleanup);
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 7/9] usb: usbip: eliminate anonymous module_init & module_exit

[Randy Dunlap]

Eliminate anonymous module_init() and module_exit(), which can lead to
confusion or ambiguity when reading System.map, crashes/oops/bugs,
or an initcall_debug log.

Give each of these init and exit functions unique driver-specific
names to eliminate the anonymous names.

Example 1: (System.map)
 832fc78c t init
 832fc79e t init
 832fc8f8 t init

Example 2: (initcall_debug log)
 calling  init+0x0/0x12 @ 1
 initcall init+0x0/0x12 returned 0 after 15 usecs
 calling  init+0x0/0x60 @ 1
 initcall init+0x0/0x60 returned 0 after 2 usecs
 calling  init+0x0/0x9a @ 1
 initcall init+0x0/0x9a returned 0 after 74 usecs

Fixes: 80fd9cd52de6 ("usbip: vudc: Add VUDC main file")
Signed-off-by: Randy Dunlap 
Cc: Krzysztof Opasiak 
Cc: Igor Kotrasinski 
Cc: Greg Kroah-Hartman 
Cc: Valentina Manea 
Cc: Shuah Khan 
Cc: Shuah Khan 
Cc: linux-...@vger.kernel.org
---
 drivers/usb/usbip/vudc_main.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- lnx-517-rc8.orig/drivers/usb/usbip/vudc_main.c
+++ lnx-517-rc8/drivers/usb/usbip/vudc_main.c
@@ -28,7 +28,7 @@ static struct platform_driver vudc_drive
 
 static struct list_head vudc_devices = LIST_HEAD_INIT(vudc_devices);
 
-static int __init init(void)
+static int __init vudc_init(void)
 {
int retval = -ENOMEM;
int i;
@@ -86,9 +86,9 @@ cleanup:
 out:
return retval;
 }
-module_init(init);
+module_init(vudc_init);
 
-static void __exit cleanup(void)
+static void __exit vudc_cleanup(void)
 {
struct vudc_device *udc_dev = NULL, *udc_dev2 = NULL;
 
@@ -103,7 +103,7 @@ static void __exit cleanup(void)
}
platform_driver_unregister(_driver);
 }
-module_exit(cleanup);
+module_exit(vudc_cleanup);
 
 MODULE_DESCRIPTION("USB over IP Device Controller");
 MODULE_AUTHOR("Krzysztof Opasiak, Karol Kosik, Igor Kotrasinski");
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5 8/8] eni_vdpa: add vDPA driver for Alibaba ENI

[Randy Dunlap]

On 10/15/21 12:15 AM, Wu Zongyong wrote:

diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
index 3d91982d8371..c0232a2148a7 100644
--- a/drivers/vdpa/Kconfig
+++ b/drivers/vdpa/Kconfig
@@ -78,4 +78,12 @@ config VP_VDPA
help
  This kernel module bridges virtio PCI device to vDPA bus.
  
+config ALIBABA_ENI_VDPA

+   tristate "vDPA driver for Alibaba ENI"
+   select VIRTIO_PCI_LEGACY_LIB
+   depends on PCI_MSI && !CPU_BIG_ENDIAN
+   help
+ VDPA driver for Alibaba ENI(Elastic Network Interface) which is build 
upon


  ENI (Elastic Network Interface) built


+ virtio 0.9.5 specification.



--
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5 16/16] x86/tdx: Add cmdline option to force use of ioremap_host_shared

[Randy Dunlap]

On 10/8/21 5:37 PM, Kuppuswamy Sathyanarayanan wrote:

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 91ba391f9b32..0af19cb1a28c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2076,6 +2076,18 @@
1 - Bypass the IOMMU for DMA.
unset - Use value of CONFIG_IOMMU_DEFAULT_PASSTHROUGH.
  
+	ioremap_force_shared= [X86_64, CCG]

+   Force the kernel to use shared memory mappings which do
+   not use ioremap_host_shared/pcimap_host_shared to opt-in
+   to shared mappings with the host. This feature is mainly
+   used by a confidential guest when enabling new drivers
+   without proper shared memory related changes. Please 
note
+   that this option might also allow other non explicitly
+   enabled drivers to interact with the host in 
confidential
+   guest, which could cause other security risks. This 
option
+   will also cause BIOS data structures to be shared with 
the
+   host, which might open security holes.


Hi,
This cmdline option text should have a little bit more info. Just as an
example/template:

acpi_apic_instance= [ACPI, IOAPIC]
Format: 
2: use 2nd APIC table, if available
1,0: use 1st APIC table
default: 0

So what is expected after the "=" sign?...

thanks.
--
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH] VDUSE: fix documentation underline warning

[Randy Dunlap]

Fix a VDUSE documentation build warning:

Documentation/userspace-api/vduse.rst:21: WARNING: Title underline too short.

Fixes: 7bc7f61897b6 ("Documentation: Add documentation for VDUSE")
Signed-off-by: Randy Dunlap 
Cc: Xie Yongji 
Cc: Jason Wang 
Cc: Michael S. Tsirkin 
Cc: virtualization@lists.linux-foundation.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/userspace-api/vduse.rst |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-515-rc4.orig/Documentation/userspace-api/vduse.rst
+++ lnx-515-rc4/Documentation/userspace-api/vduse.rst
@@ -18,7 +18,7 @@ types can be added after the security is
 is clarified or fixed in the future.
 
 Create/Destroy VDUSE devices
-
+
 
 VDUSE devices are created as follows:
 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 1/5] virtio-pci: introduce legacy device module

[Randy Dunlap]

On 9/14/21 5:24 AM, Wu Zongyong wrote:

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index ce1b3f6ec325..b14768dc9e04 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -20,6 +20,15 @@ config VIRTIO_PCI_LIB
  PCI device with possible vendor specific extensions. Any
  module that selects this module must depend on PCI.
  
+config VIRTIO_PCI_LIB_LEGACY

+   tristate
+   help
+ Legacy PCI device (Virtio PCI Card 0.9.x Draft and older device)
+ implementation.
+ This modules implements the basic probe and control for devices


   module


+ which are based on legacy PCI device. Any module that selects this
+ module must depend on PCI.
+



--
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 5/5] eni_vdpa: add vDPA driver for Alibaba ENI

[Randy Dunlap]

On 9/14/21 5:24 AM, Wu Zongyong wrote:

diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
index 3d91982d8371..9587b9177b05 100644
--- a/drivers/vdpa/Kconfig
+++ b/drivers/vdpa/Kconfig
@@ -78,4 +78,12 @@ config VP_VDPA
help
  This kernel module bridges virtio PCI device to vDPA bus.
  
+config ALIBABA_ENI_VDPA

+   tristate "vDPA driver for Alibaba ENI"
+   select VIRTIO_PCI_LEGACY_LIB
+   depends on PCI_MSI
+   help
+ VDPA driver for Alibaba ENI(Elastic Network Interface) which is build 
upon


  ENI (Elasticbuilt 
upon the


+ virtio 0.9.5 specification.
+
  endif # VDPA



--
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 03/19] drivers/hv: minimal mshv module (/dev/mshv/)

[Randy Dunlap]

On 5/28/21 3:43 PM, Nuno Das Neves wrote:
> Introduce a barebones module file for the mshv API.
> Introduce CONFIG_HYPERV_ROOT_API for controlling compilation of mshv.
> 
> Co-developed-by: Lillian Grassin-Drake 
> Signed-off-by: Lillian Grassin-Drake 
> Signed-off-by: Nuno Das Neves 
> ---

Hi,

> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> index 66c794d92391..d618b1fab2bb 100644
> --- a/drivers/hv/Kconfig
> +++ b/drivers/hv/Kconfig
> @@ -27,4 +27,22 @@ config HYPERV_BALLOON
>   help
> Select this option to enable Hyper-V Balloon driver.
>  
> +config HYPERV_ROOT_API
> + tristate "Microsoft Hypervisor root partition interfaces: /dev/mshv"
> + depends on HYPERV
> + help
> +   Provides access to interfaces for managing guest virtual machines
> +   running under the Microsoft Hypervisor.
> +
> +   These interfaces will only work when Linux is running as root
> +   partition on the Microsoft Hypervisor.
> +
> +   The interfaces are provided via a device named /dev/mshv.
> +
> +   To compile this as a module, choose M here.
> +  The module is named mshv.

^

Please follow coding-style for Kconfig files:

(from Documentation/process/coding-style.rst, section 10):

For all of the Kconfig* configuration files throughout the source tree,
the indentation is somewhat different.  Lines under a ``config`` definition
are indented with one tab, while help text is indented an additional two
spaces.

> +
> +   If unsure, say N.
> +
> +
>  endmenu

thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH] sound: virtio: correct the function name in kernel-doc comment

[Randy Dunlap]

Fix kernel-doc warning that the wrong function name is used in a
kernel-doc comment:

../sound/virtio/virtio_ctl_msg.c:70: warning: expecting prototype for 
virtsnd_ctl_msg_request(). Prototype was for virtsnd_ctl_msg_response() instead

Signed-off-by: Randy Dunlap 
Cc: Anton Yakovlev 
Cc: "Michael S. Tsirkin" 
Cc: virtualization@lists.linux-foundation.org
Cc: alsa-de...@alsa-project.org
---
 sound/virtio/virtio_ctl_msg.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20210414.orig/sound/virtio/virtio_ctl_msg.c
+++ linux-next-20210414/sound/virtio/virtio_ctl_msg.c
@@ -61,7 +61,7 @@ void *virtsnd_ctl_msg_request(struct vir
 }
 
 /**
- * virtsnd_ctl_msg_request() - Get a pointer to the response header.
+ * virtsnd_ctl_msg_response() - Get a pointer to the response header.
  * @msg: Control message.
  *
  * Context: Any context.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Mar 11 [drivers/vdpa/virtio_pci/vp_vdpa.ko]

[Randy Dunlap]

On 3/10/21 9:14 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Warning: Some of the branches in linux-next are still based on v5.12-rc1,
> so please be careful if you are trying to bisect a bug.
> 
> News: if your -next included tree is based on Linus' tree tag
> v5.12-rc1{,-dontuse} (or somewhere between v5.11 and that tag), please
> consider rebasing it onto v5.12-rc2. Also, please check any branches
> merged into your branch.
> 
> Changes since 20210310:
> 

on i386:

ERROR: modpost: "vp_modern_get_queue_notify_off" 
[drivers/vdpa/virtio_pci/vp_vdpa.ko] undefined!
ERROR: modpost: "vp_modern_get_num_queues" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_probe" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_queue_address" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_set_queue_size" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_set_queue_enable" 
[drivers/vdpa/virtio_pci/vp_vdpa.ko] undefined!
ERROR: modpost: "vp_modern_get_queue_enable" 
[drivers/vdpa/virtio_pci/vp_vdpa.ko] undefined!
ERROR: modpost: "vp_modern_get_features" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_set_features" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_set_status" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_get_status" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_config_vector" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_queue_vector" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_generation" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!
ERROR: modpost: "vp_modern_remove" [drivers/vdpa/virtio_pci/vp_vdpa.ko] 
undefined!


Full randconfig file is attached.

-- 
~Randy
Reported-by: Randy Dunlap 


config-r8169.gz
Description: application/gzip
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC v3 08/11] vduse: Introduce VDUSE - vDPA Device in Userspace

[Randy Dunlap]

Hi,

Documentation comments only:

On 1/18/21 9:07 PM, Xie Yongji wrote:
> 
> Signed-off-by: Xie Yongji 
> ---
>  Documentation/driver-api/vduse.rst |   85 ++
> 
> diff --git a/Documentation/driver-api/vduse.rst 
> b/Documentation/driver-api/vduse.rst
> new file mode 100644
> index ..9418a7f6646b
> --- /dev/null
> +++ b/Documentation/driver-api/vduse.rst
> @@ -0,0 +1,85 @@
> +==
> +VDUSE - "vDPA Device in Userspace"
> +==
> +
> +vDPA (virtio data path acceleration) device is a device that uses a
> +datapath which complies with the virtio specifications with vendor
> +specific control path. vDPA devices can be both physically located on
> +the hardware or emulated by software. VDUSE is a framework that makes it
> +possible to implement software-emulated vDPA devices in userspace.
> +
> +How VDUSE works
> +
> +Each userspace vDPA device is created by the VDUSE_CREATE_DEV ioctl on
> +the VDUSE character device (/dev/vduse). Then a file descriptor pointing
> +to the new resources will be returned, which can be used to implement the
> +userspace vDPA device's control path and data path.
> +
> +To implement control path, the read/write operations to the file descriptor
> +will be used to receive/reply the control messages from/to VDUSE driver.
> +Those control messages are mostly based on the vdpa_config_ops which defines
> +a unified interface to control different types of vDPA device.
> +
> +The following types of messages are provided by the VDUSE framework now:
> +
> +- VDUSE_SET_VQ_ADDR: Set the addresses of the different aspects of virtqueue.
> +
> +- VDUSE_SET_VQ_NUM: Set the size of virtqueue
> +
> +- VDUSE_SET_VQ_READY: Set ready status of virtqueue
> +
> +- VDUSE_GET_VQ_READY: Get ready status of virtqueue
> +
> +- VDUSE_SET_VQ_STATE: Set the state (last_avail_idx) for virtqueue
> +
> +- VDUSE_GET_VQ_STATE: Get the state (last_avail_idx) for virtqueue
> +
> +- VDUSE_SET_FEATURES: Set virtio features supported by the driver
> +
> +- VDUSE_GET_FEATURES: Get virtio features supported by the device
> +
> +- VDUSE_SET_STATUS: Set the device status
> +
> +- VDUSE_GET_STATUS: Get the device status
> +
> +- VDUSE_SET_CONFIG: Write to device specific configuration space
> +
> +- VDUSE_GET_CONFIG: Read from device specific configuration space
> +
> +- VDUSE_UPDATE_IOTLB: Notify userspace to update the memory mapping in 
> device IOTLB
> +
> +Please see include/linux/vdpa.h for details.
> +
> +In the data path, vDPA device's iova regions will be mapped into userspace 
> with
> +the help of VDUSE_IOTLB_GET_FD ioctl on the userspace vDPA device fd:
> +
> +- VDUSE_IOTLB_GET_FD: get the file descriptor to iova region. Userspace can
> +  access this iova region by passing the fd to mmap(2).
> +
> +Besides, the eventfd mechanism is used to trigger interrupt callbacks and
> +receive virtqueue kicks in userspace. The following ioctls on the userspace
> +vDPA device fd are provided to support that:
> +
> +- VDUSE_VQ_SETUP_KICKFD: set the kickfd for virtqueue, this eventfd is used
> +  by VDUSE driver to notify userspace to consume the vring.
> +
> +- VDUSE_VQ_SETUP_IRQFD: set the irqfd for virtqueue, this eventfd is used
> +  by userspace to notify VDUSE driver to trigger interrupt callbacks.
> +
> +MMU-based IOMMU Driver
> +--
> +In virtio-vdpa case, VDUSE framework implements a MMU-based on-chip IOMMU

   an MMU-based

> +driver to support mapping the kernel dma buffer into the userspace iova

DMA

> +region dynamically.
> +
> +The basic idea behind this driver is treating MMU (VA->PA) as IOMMU 
> (IOVA->PA).
> +The driver will set up MMU mapping instead of IOMMU mapping for the DMA 
> transfer
> +so that the userspace process is able to use its virtual address to access
> +the dma buffer in kernel.

   DMA

> +
> +And to avoid security issue, a bounce-buffering mechanism is introduced to
> +prevent userspace accessing the original buffer directly which may contain 
> other
> +kernel data. During the mapping, unmapping, the driver will copy the data 
> from
> +the original buffer to the bounce buffer and back, depending on the 
> direction of
> +the transfer. And the bounce-buffer addresses will be mapped into the user 
> address
> +space instead of the original one.


thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3] drivers: gpio: add virtio-gpio guest driver

[Randy Dunlap]

On 12/7/20 12:48 PM, Enrico Weigelt, metux IT consult wrote:
> Introducing new GPIO driver for virtual GPIO devices via virtio.
> 

Oops, I missed one thing:


> 
> diff --git a/Documentation/gpio/virtio-gpio.rst 
> b/Documentation/gpio/virtio-gpio.rst
> new file mode 100644
> index ..e7bf01ec1ce7
> --- /dev/null
> +++ b/Documentation/gpio/virtio-gpio.rst
> @@ -0,0 +1,176 @@
> +"
> +Virtio-GPIO protocol specification
> +"


In Documentation/doc-guide/sphinx.rst, it says to please use the
following heading adornments
and "..." is not one of them.

Neither is "..".

Also, only use an overline for the document title and not for
lower level headings.

Here are the expected heading adornments:

  1. ``=`` with overline for document title::

   ==
   Document title
   ==

  2. ``=`` for chapters::

   Chapters
   

  3. ``-`` for sections::

   Section
   ---

  4. ``~`` for subsections::

   Subsection
   ~~


> +...
> +Specification for virtio-based virtiual GPIO devices
> +...
> +
> ++
> ++Version_ 1.0
> ++
> +
> +===
> +General
> +===
> +
> +The virtio-gpio protocol provides access to general purpose IO devices
> +to virtual machine guests. These virtualized GPIOs could be either provided
> +by some simulator (eg. virtual HIL), routed to some external device or
> +routed to real GPIOs on the host (eg. virtualized embedded applications).
> +
> +Instead of simulating some existing real GPIO chip within an VMM, this
> +protocol provides an hardware independent interface between host and guest
> +that solely relies on an active virtio connection (no matter which transport
> +actually used), no other buses or additional platform driver logic required.
> +
> +===
> +Protocol layout
> +===
> +
> +--
> +Configuration space
> +--


thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3] drivers: gpio: add virtio-gpio guest driver

[Randy Dunlap]

On 12/7/20 12:48 PM, Enrico Weigelt, metux IT consult wrote:
> Introducing new GPIO driver for virtual GPIO devices via virtio.

  Introduce

> 
> The driver allows routing GPIO control into VM guests, eg. brigding
> virtual gpios to specific host gpios, or attaching simulators for
> automatic application testing.
> 

These ...

> Changes v3:
> * spec: fixed type names
> * spec: replace "host"/"guest" by "device"/"cpu"
> * spec: change terminology from "events" to "messages"
> * driver: fixed missing can_sleep flag
> * driver: select VIRTIO instead of depends on
> * driver: drop references to qemu in Kconfig
> * driver: fixed incomplete error handling and possible deadlock
>   in case of sending buf failed
> * driver: dropped unneeded WARN_ON
> * driver: fixed retval of virtio_gpio_xmit()
> * driver: dynamically allocate virtio buffers
> * driver: added locking on gpio operations
> * driver: added irq_chip functions
> 
> Changes v2:
> * uapi: fixed header license
> * driver: sorted include's
> * driver: fixed formatting
> * driver: fixed unneeded devm allocation - plain kzalloc/kfree is enough
> * driver: fixed missing devm_kzalloc fail check
> * driver: use devm_kcalloc() for array allocation
> * spec: added virtio-gpio protocol specification

... Vx change descriptions go after the following "---" line.
I usually put them before the diffstat, with one blank line
separating them.

> 
> Signed-off-by: Enrico Weigelt, metux IT consult 
> ---
>  Documentation/gpio/virtio-gpio.rst | 176 +
>  MAINTAINERS|   6 +
>  drivers/gpio/Kconfig   |   7 +
>  drivers/gpio/Makefile  |   1 +
>  drivers/gpio/gpio-virtio.c | 381 
> +
>  include/uapi/linux/virtio_gpio.h   |  39 
>  include/uapi/linux/virtio_ids.h|   1 +
>  7 files changed, 611 insertions(+)
>  create mode 100644 Documentation/gpio/virtio-gpio.rst
>  create mode 100644 drivers/gpio/gpio-virtio.c
>  create mode 100644 include/uapi/linux/virtio_gpio.h
> 
> diff --git a/Documentation/gpio/virtio-gpio.rst 
> b/Documentation/gpio/virtio-gpio.rst
> new file mode 100644
> index ..e7bf01ec1ce7
> --- /dev/null
> +++ b/Documentation/gpio/virtio-gpio.rst
> @@ -0,0 +1,176 @@
> +"
> +Virtio-GPIO protocol specification
> +"
> +...
> +Specification for virtio-based virtiual GPIO devices

  virtual
although it seems redundant.

> +...
> +
> ++
> ++Version_ 1.0
> ++
> +
> +===
> +General
> +===
> +
> +The virtio-gpio protocol provides access to general purpose IO devices
> +to virtual machine guests. These virtualized GPIOs could be either provided

   in  (?)

> +by some simulator (eg. virtual HIL), routed to some external device or

 (e.g.

> +routed to real GPIOs on the host (eg. virtualized embedded applications).

(e.g.

> +
> +Instead of simulating some existing real GPIO chip within an VMM, this

  within a
and why not just "VM"?

> +protocol provides an hardware independent interface between host and guest

 a hardware

> +that solely relies on an active virtio connection (no matter which transport
> +actually used), no other buses or additional platform driver logic required.
> +
> +===
> +Protocol layout
> +===
> +
> +--
> +Configuration space
> +--
> +
> +++--+---+
> +| Offset | Type | Description   |
> +++==+===+
> +| 0x00   | u8   | version   |
> +++--+---+
> +| 0x02   | u16  | number of GPIO lines  |
> +++--+---+
> +| 0x04   | u32  | size of gpio name block   |
> +++--+---+
> +| 0x20   | char[32] | device name (0-terminated)|
> +++--+---+
> +| 0x40   | char[]   | line names block  |
> +++--+---+
> +
> +- for version field currently only value 1 supported.
> +- the line names block holds a stream of zero-terminated strings,
> +  holding the individual line names.
> +- unspecified fields are reserved for future use and should be zero.
> +
> +
> +Virtqueues and messages:
> +
> +
> +- Queue #0: transmission from device to cpu

   CPU

> +- Queue #1: transmission from cpu to device

 CPU

> +
> +The queues transport messages of 

Re: [PATCH V2 19/19] vdpa: introduce virtio pci driver

[Randy Dunlap]

On 12/4/20 7:20 AM, Stefano Garzarella wrote:
> On Fri, Dec 04, 2020 at 12:03:53PM +0800, Jason Wang wrote:
>> This patch introduce a vDPA driver for virtio-pci device. It bridges
>> the virtio-pci control command to the vDPA bus. This will be used for
>> features prototyping and testing.
>>
>> Note that get/restore virtqueue state is not supported which needs
>> extension on the virtio specification.
>>
>> Signed-off-by: Jason Wang 
>> ---
>> drivers/vdpa/Kconfig  |   6 +
>> drivers/vdpa/Makefile |   1 +
>> drivers/vdpa/virtio_pci/Makefile  |   2 +
>> drivers/vdpa/virtio_pci/vp_vdpa.c | 455 ++
>> 4 files changed, 464 insertions(+)
>> create mode 100644 drivers/vdpa/virtio_pci/Makefile
>> create mode 100644 drivers/vdpa/virtio_pci/vp_vdpa.c
>>
>> diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
>> index 358f6048dd3c..18cad14f533e 100644
>> --- a/drivers/vdpa/Kconfig
>> +++ b/drivers/vdpa/Kconfig
>> @@ -48,4 +48,10 @@ config MLX5_VDPA_NET
>>   be executed by the hardware. It also supports a variety of stateless
>>   offloads depending on the actual device used and firmware version.
>>
>> +config VP_VDPA
>> +    tristate "Virtio PCI bridge vDPA driver"
>> +    depends on PCI_MSI && VIRTIO_PCI_MODERN
>> +    help
>> +  This kernel module that bridges virtio PCI device to vDPA bus.
>  ^
> Without 'that' maybe sound better, but I'm not a native speaker :-)

Yes, drop 'that', please.

>> +
>> endif # VDPA

-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V2 16/19] virtio-pci: introduce modern device module

[Randy Dunlap]

Hi Jason--

On 12/3/20 8:03 PM, Jason Wang wrote:
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 7b41130d3f35..d1a6bd2a975f 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -12,6 +12,14 @@ config ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> This option is selected if the architecture may need to enforce
> VIRTIO_F_ACCESS_PLATFORM
>  
> +config VIRTIO_PCI_MODERN
> + tristate "Modern Virtio PCI Device"
> + depends on PCI
> + help
> +   Modern PCI device implementation. This module implement the

implements

> +   basic probe and control for devices which is based on modern

are

> +   PCI device with possible vendor specific extensions.

  devices
> +


cheers.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 02/19] vdpa_sim: remove unnecessary headers inclusion

[Randy Dunlap]

On 12/3/20 9:04 AM, Stefano Garzarella wrote:
> Some headers are not necessary, so let's remove them to do
> some cleaning.
> 
> Signed-off-by: Stefano Garzarella 

Hi,
What makes you say that some of these are unnecessary?

Please use Rule #1 from Documentation/process/submit-checklist.rst:

1) If you use a facility then #include the file that defines/declares
   that facility.  Don't depend on other header files pulling in ones
   that you use.


so just because it will compile without these headers being explictly
#included does not mean that you should remove them.


> ---
> v3:
> - avoided to remove some headers with structures and functions directly
>   used (device.h, slab.h, virtio_byteorder.h)[Jason]
> ---
>  drivers/vdpa/vdpa_sim/vdpa_sim.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c 
> b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> index 6a90fdb9cbfc..b08f28d20d8d 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
> @@ -7,20 +7,10 @@
>   *
>   */
>  
> -#include 

above is used by __init and __exit.

>  #include 
>  #include 
> -#include 
> -#include 
> -#include 

Looks OK to remove poll.h.

>  #include 
> -#include 

Might be OK for sched.h.

> -#include 

Might be OK for wait.h.

> -#include 
> -#include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> 

I didn't check the others.


-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 19/19] vdpa: split vdpasim to core and net modules

[Randy Dunlap]

Hi,

On 12/3/20 9:05 AM, Stefano Garzarella wrote:
> diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
> index 2c892e890b9e..b0f91ad8eb47 100644
> --- a/drivers/vdpa/Kconfig
> +++ b/drivers/vdpa/Kconfig
> @@ -9,15 +9,20 @@ menuconfig VDPA
>  if VDPA
>  
>  config VDPA_SIM
> - tristate "vDPA device simulator"
> + tristate "vDPA device simulator core"
>   depends on RUNTIME_TESTING_MENU && HAS_DMA
>   select DMA_OPS
>   select VHOST_RING
> + help
> +   Enable this module to support vDPA device simulators. These devices
> +   are used for testing, prototyping and development of vDPA.
> +
> +config VDPA_SIM_NET
> + tristate "vDPA simulator for networking device"
> + depends on VDPA_SIM
>   select GENERIC_NET_UTILS
>   help
> -   vDPA networking device simulator which loop TX traffic back
> -   to RX. This device is used for testing, prototyping and
> -   development of vDPA.
> +   vDPA networking device simulator which loop TX traffic back to RX.

 loops


thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v4] vdpa: mlx5: fix vdpa/vhost dependencies

[Randy Dunlap]

drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so select
VHOST_IOTLB to make them be built.

However, if VHOST_IOTLB is the only VHOST symbol that is
set/enabled, the object file still won't be built because
drivers/Makefile won't descend into drivers/vhost/ to build it,
so make drivers/Makefile build the needed binary whenever
VHOST_IOTLB is set, like it does for VHOST_RING.

Fixes these build errors:
ERROR: modpost: "vhost_iotlb_itree_next" [drivers/vdpa/mlx5/mlx5_vdpa.ko] 
undefined!
ERROR: modpost: "vhost_iotlb_itree_first" [drivers/vdpa/mlx5/mlx5_vdpa.ko] 
undefined!

Fixes: 29064bfdabd5 ("vdpa/mlx5: Add support library for mlx5 VDPA 
implementation")
Fixes: aff90770e54c ("vdpa/mlx5: Fix dependency on MLX5_CORE")
Reported-by: kernel test robot 
Signed-off-by: Randy Dunlap 
Cc: Eli Cohen 
Cc: Parav Pandit 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: virtualization@lists.linux-foundation.org
Cc: Saeed Mahameed 
Cc: Leon Romanovsky 
Cc: net...@vger.kernel.org
---
v2: change from select to depends on VHOST (Saeed)
v3: change to depends on VHOST_IOTLB (Jason)
v4: use select VHOST_IOTLB (Michael); also add to drivers/Makefile

 drivers/Makefile |1 +
 drivers/vdpa/Kconfig |1 +
 2 files changed, 2 insertions(+)

--- linux-next-20201127.orig/drivers/vdpa/Kconfig
+++ linux-next-20201127/drivers/vdpa/Kconfig
@@ -32,6 +32,7 @@ config IFCVF
 
 config MLX5_VDPA
bool
+   select VHOST_IOTLB
help
  Support library for Mellanox VDPA drivers. Provides code that is
  common for all types of VDPA drivers. The following drivers are 
planned:
--- linux-next-20201127.orig/drivers/Makefile
+++ linux-next-20201127/drivers/Makefile
@@ -143,6 +143,7 @@ obj-$(CONFIG_OF)+= of/
 obj-$(CONFIG_SSB)  += ssb/
 obj-$(CONFIG_BCMA) += bcma/
 obj-$(CONFIG_VHOST_RING)   += vhost/
+obj-$(CONFIG_VHOST_IOTLB)  += vhost/
 obj-$(CONFIG_VHOST)+= vhost/
 obj-$(CONFIG_VLYNQ)+= vlynq/
 obj-$(CONFIG_GREYBUS)  += greybus/
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] drivers: gpio: add virtio-gpio guest driver

[Randy Dunlap]

On 11/27/20 10:30 AM, Enrico Weigelt, metux IT consult wrote:
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 5d4de5cd6759..e8414d82cf75 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1613,4 +1613,13 @@ config GPIO_MOCKUP
> tools/testing/selftests/gpio/gpio-mockup.sh. Reference the usage in
> it.
>  
> +config GPIO_VIRTIO
> + tristate "VirtIO GPIO support"
> + depends on VIRTIO
> + help
> +   Say Y here to enable guest support for virtio based GPIOs.

 virtio-based

> +
> +   These virtual gpios can be routed to real GPIOs or attached to

GPIOs

> +   simulators on the host (qemu).
> +
>  endif


-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vdpasim: fix "mac_pton" undefined error

[Randy Dunlap]

On 11/13/20 10:49 AM, Randy Dunlap wrote:
> On 11/13/20 7:57 AM, Laurent Vivier wrote:
>>ERROR: modpost: "mac_pton" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined!
>>
>> mac_pton() is defined in lib/net_utils.c and is not built if NET is not set.
>>
>> Select GENERIC_NET_UTILS as vdpasim doesn't depend on NET.
>>
>> Reported-by: kernel test robot 
> 
> On Nov. 2, 2020:
> 
> Reported-by: Randy Dunlap 
> 
> https://lore.kernel.org/lkml/d3d50a94-cdc5-572b-e9ca-3ee5638d2...@infradead.org/
> 
> 
>> Signed-off-by: Laurent Vivier 
>> ---
>>  drivers/vdpa/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
>> index d7d32b656102..358f6048dd3c 100644
>> --- a/drivers/vdpa/Kconfig
>> +++ b/drivers/vdpa/Kconfig
>> @@ -13,6 +13,7 @@ config VDPA_SIM
>>  depends on RUNTIME_TESTING_MENU && HAS_DMA
>>  select DMA_OPS
>>  select VHOST_RING
>> +select GENERIC_NET_UTILS
>>  default n
>>  help
>>vDPA networking device simulator which loop TX traffic back
>>
> 
> Thanks for the patch.

Acked-by: Randy Dunlap  # build-tested

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vdpasim: fix "mac_pton" undefined error

[Randy Dunlap]

On 11/13/20 7:57 AM, Laurent Vivier wrote:
>ERROR: modpost: "mac_pton" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined!
> 
> mac_pton() is defined in lib/net_utils.c and is not built if NET is not set.
> 
> Select GENERIC_NET_UTILS as vdpasim doesn't depend on NET.
> 
> Reported-by: kernel test robot 

On Nov. 2, 2020:

Reported-by: Randy Dunlap 

https://lore.kernel.org/lkml/d3d50a94-cdc5-572b-e9ca-3ee5638d2...@infradead.org/


> Signed-off-by: Laurent Vivier 
> ---
>  drivers/vdpa/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
> index d7d32b656102..358f6048dd3c 100644
> --- a/drivers/vdpa/Kconfig
> +++ b/drivers/vdpa/Kconfig
> @@ -13,6 +13,7 @@ config VDPA_SIM
>   depends on RUNTIME_TESTING_MENU && HAS_DMA
>   select DMA_OPS
>   select VHOST_RING
> + select GENERIC_NET_UTILS
>   default n
>   help
> vDPA networking device simulator which loop TX traffic back
> 

Thanks for the patch.

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Nov 2 [drivers/vdpa/vdpa_sim/vdpa_sim.ko]

[Randy Dunlap]

On 11/1/20 9:28 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20201030:
> 

on x86_64:

when CONFIG_NET is not enabled:

ERROR: modpost: "mac_pton" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined!


Should VDPA_SIM, IFCVF, MLX5_VDPA_NET depend on NET or NETDEVICES?



-- 
~Randy
Reported-by: Randy Dunlap 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC 2/4] vduse: Introduce VDUSE - vDPA Device in Userspace

[Randy Dunlap]

On 10/19/20 8:08 AM, Michael S. Tsirkin wrote:
> On Mon, Oct 19, 2020 at 10:56:21PM +0800, Xie Yongji wrote:
>> diff --git a/include/uapi/linux/vduse.h b/include/uapi/linux/vduse.h

>> +#define VDUSE_BASE  'V'
>> +
> 
> Could we see some documentation about the user interface of this module 
> please?
> 

Also, the VDUSE_BASE value should be documented in
Documentation/userspace-api/ioctl/ioctl-number.rst.

thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo

[Randy Dunlap]

On 10/13/20 8:12 AM, Mike Rapoport wrote:
> On Tue, Oct 13, 2020 at 07:43:59AM -0700, Randy Dunlap wrote:
>> On 10/13/20 1:09 AM, Mike Rapoport wrote:
>>> On Mon, Oct 12, 2020 at 05:53:01PM +0800, Muchun Song wrote:
>>>> On Mon, Oct 12, 2020 at 5:24 PM Eric Dumazet  
>>>> wrote:
>>>>>
>>>>> On 10/12/20 10:39 AM, Muchun Song wrote:
>>>>>> On Mon, Oct 12, 2020 at 3:42 PM Eric Dumazet  wrote:
>>>>
>>>> We are not complaining about TCP using too much memory, but how do
>>>> we know that TCP uses a lot of memory. When I firstly face this problem,
>>>> I do not know who uses the 25GB memory and it is not shown in the 
>>>> /proc/meminfo.
>>>> If we can know the amount memory of the socket buffer via /proc/meminfo, we
>>>> may not need to spend a lot of time troubleshooting this problem. Not 
>>>> everyone
>>>> knows that a lot of memory may be used here. But I believe many people
>>>> should know /proc/meminfo to confirm memory users.
>>>
>>> If I undestand correctly, the problem you are trying to solve is to
>>> simplify troubleshooting of memory usage for people who may not be aware
>>> that networking stack can be a large memory consumer.
>>>
>>> For that a paragraph in 'man 5 proc' maybe a good start:
>>>
>>> >From ddbcf38576d1a2b0e36fe25a27350d566759b664 Mon Sep 17 00:00:00 2001
>>> From: Mike Rapoport 
>>> Date: Tue, 13 Oct 2020 11:07:35 +0300
>>> Subject: [PATCH] proc.5: meminfo: add not anout network stack memory
>>>  consumption
>>>
>>> Signed-off-by: Mike Rapoport 
>>> ---
>>>  man5/proc.5 | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/man5/proc.5 b/man5/proc.5
>>> index ed309380b..8414676f1 100644
>>> --- a/man5/proc.5
>>> +++ b/man5/proc.5
>>> @@ -3478,6 +3478,14 @@ Except as noted below,
>>>  all of the fields have been present since at least Linux 2.6.0.
>>>  Some fields are displayed only if the kernel was configured
>>>  with various options; those dependencies are noted in the list.
>>> +.IP
>>> +Note that significant part of memory allocated by the network stack
>>> +is not accounted in the file.
>>> +The memory consumption of the network stack can be queried
>>> +using
>>> +.IR /proc/net/sockstat
>>> +or
>>> +.BR ss (8)
>>>  .RS
>>>  .TP
>>>  .IR MemTotal " %lu"
>>
>> Hi Mike,
>>
>> Could you tell us what units those values are in?
>> or is that already explained somewhere else?
> 
> It is described a few lines above and anyway, "MemTotal" is a part of
> the diff context ;-)

with no units AFAICT.

But I was unclear. I wasn't referring to /proc/meminfo, but instead
to /proc/net/sockstat and its units:

sockets: used 1224
TCP: inuse 11 orphan 1 tw 1 alloc 26 mem 3
UDP: inuse 4 mem 2
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

E.g., for TCP and UDP, are those socket counts or some unit of memory?
If units of memory, what unit size?

thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo

[Randy Dunlap]

On 10/13/20 1:09 AM, Mike Rapoport wrote:
> On Mon, Oct 12, 2020 at 05:53:01PM +0800, Muchun Song wrote:
>> On Mon, Oct 12, 2020 at 5:24 PM Eric Dumazet  wrote:
>>>
>>> On 10/12/20 10:39 AM, Muchun Song wrote:
 On Mon, Oct 12, 2020 at 3:42 PM Eric Dumazet  wrote:
>
> On Mon, Oct 12, 2020 at 6:22 AM Muchun Song  
> wrote:
>>
>> On Mon, Oct 12, 2020 at 2:39 AM Cong Wang  
>> wrote:
>>>
>>> On Sat, Oct 10, 2020 at 3:39 AM Muchun Song  
>>> wrote:

 The amount of memory allocated to sockets buffer can become 
 significant.
 However, we do not display the amount of memory consumed by sockets
 buffer. In this case, knowing where the memory is consumed by the 
 kernel
>>>
>>> We do it via `ss -m`. Is it not sufficient? And if not, why not adding 
>>> it there
>>> rather than /proc/meminfo?
>>
>> If the system has little free memory, we can know where the memory is via
>> /proc/meminfo. If a lot of memory is consumed by socket buffer, we cannot
>> know it when the Sock is not shown in the /proc/meminfo. If the unaware 
>> user
>> can't think of the socket buffer, naturally they will not `ss -m`. The
>> end result
>> is that we still don’t know where the memory is consumed. And we add the
>> Sock to the /proc/meminfo just like the memcg does('sock' item in the 
>> cgroup
>> v2 memory.stat). So I think that adding to /proc/meminfo is sufficient.
>>
>>>
  static inline void __skb_frag_unref(skb_frag_t *frag)
  {
 -   put_page(skb_frag_page(frag));
 +   struct page *page = skb_frag_page(frag);
 +
 +   if (put_page_testzero(page)) {
 +   dec_sock_node_page_state(page);
 +   __put_page(page);
 +   }
  }
>>>
>>> You mix socket page frag with skb frag at least, not sure this is 
>>> exactly
>>> what you want, because clearly skb page frags are frequently used
>>> by network drivers rather than sockets.
>>>
>>> Also, which one matches this dec_sock_node_page_state()? Clearly
>>> not skb_fill_page_desc() or __skb_frag_ref().
>>
>> Yeah, we call inc_sock_node_page_state() in the skb_page_frag_refill().
>> So if someone gets the page returned by skb_page_frag_refill(), it must
>> put the page via __skb_frag_unref()/skb_frag_unref(). We use PG_private
>> to indicate that we need to dec the node page state when the refcount of
>> page reaches zero.
>>
>
> Pages can be transferred from pipe to socket, socket to pipe (splice()
> and zerocopy friends...)
>
>  If you want to track TCP memory allocations, you always can look at
> /proc/net/sockstat,
> without adding yet another expensive memory accounting.

 The 'mem' item in the /proc/net/sockstat does not represent real
 memory usage. This is just the total amount of charged memory.

 For example, if a task sends a 10-byte message, it only charges one
 page to memcg. But the system may allocate 8 pages. Therefore, it
 does not truly reflect the memory allocated by the above memory
 allocation path. We can see the difference via the following message.

 cat /proc/net/sockstat
   sockets: used 698
   TCP: inuse 70 orphan 0 tw 617 alloc 134 mem 13
   UDP: inuse 90 mem 4
   UDPLITE: inuse 0
   RAW: inuse 1
   FRAG: inuse 0 memory 0

 cat /proc/meminfo | grep Sock
   Sock:  13664 kB

 The /proc/net/sockstat only shows us that there are 17*4 kB TCP
 memory allocations. But apply this patch, we can see that we truly
 allocate 13664 kB(May be greater than this value because of per-cpu
 stat cache). Of course the load of the example here is not high. In
 some high load cases, I believe the difference here will be even
 greater.

>>>
>>> This is great, but you have not addressed my feedback.
>>>
>>> TCP memory allocations are bounded by /proc/sys/net/ipv4/tcp_mem
>>>
>>> Fact that the memory is forward allocated or not is a detail.
>>>
>>> If you think we must pre-allocate memory, instead of forward allocations,
>>> your patch does not address this. Adding one line per consumer in 
>>> /proc/meminfo looks
>>> wrong to me.
>>
>> I think that the consumer which consumes a lot of memory should be added
>> to the /proc/meminfo. This can help us know the user of large memory.
>>
>>>
>>> If you do not want 9.37 % of physical memory being possibly used by TCP,
>>> just change /proc/sys/net/ipv4/tcp_mem accordingly ?
>>
>> We are not complaining about TCP using too much memory, but how do
>> we know that TCP uses a lot of memory. When I firstly face this problem,
>> I do not know who uses the 25GB memory and it is not shown in the 
>> /proc/meminfo.
>> If we can know the amount memory of the socket buffer via 

Re: [PATCH] mm: proc: add Sock to /proc/meminfo

[Randy Dunlap]

Hi,

On 10/10/20 3:38 AM, Muchun Song wrote:
> The amount of memory allocated to sockets buffer can become significant.
> However, we do not display the amount of memory consumed by sockets
> buffer. In this case, knowing where the memory is consumed by the kernel
> is very difficult. On our server with 500GB RAM, sometimes we can see
> 25GB disappear through /proc/meminfo. After our analysis, we found the
> following memory allocation path which consumes the memory with page_owner
> enabled.
> 
>   849698 times:
>   Page allocated via order 3, mask 
> 0x4052c0(GFP_NOWAIT|__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP)
>__alloc_pages_nodemask+0x11d/0x290
>skb_page_frag_refill+0x68/0xf0
>sk_page_frag_refill+0x19/0x70
>tcp_sendmsg_locked+0x2f4/0xd10
>tcp_sendmsg+0x29/0xa0
>sock_sendmsg+0x30/0x40
>sock_write_iter+0x8f/0x100
>__vfs_write+0x10b/0x190
>vfs_write+0xb0/0x190
>ksys_write+0x5a/0xd0
>do_syscall_64+0x5d/0x110
>entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> Signed-off-by: Muchun Song 
> ---
>  drivers/base/node.c  |  2 ++
>  drivers/net/virtio_net.c |  3 +--
>  fs/proc/meminfo.c|  1 +
>  include/linux/mmzone.h   |  1 +
>  include/linux/skbuff.h   | 43 ++--
>  kernel/exit.c|  3 +--
>  mm/page_alloc.c  |  7 +--
>  mm/vmstat.c  |  1 +
>  net/core/sock.c  |  8 
>  net/ipv4/tcp.c   |  3 +--
>  net/xfrm/xfrm_state.c|  3 +--
>  11 files changed, 59 insertions(+), 16 deletions(-)

Thanks for finding that.

Please update Documentation/filesystems/proc.rst "meminfo" section also.

-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 -next] vdpa: mlx5: change Kconfig depends to fix build errors

[Randy Dunlap]

On 9/24/20 3:24 AM, Eli Cohen wrote:
> On Thu, Sep 24, 2020 at 05:30:55AM -0400, Michael S. Tsirkin wrote:
 --- linux-next-20200917.orig/drivers/vdpa/Kconfig
 +++ linux-next-20200917/drivers/vdpa/Kconfig
 @@ -31,7 +31,7 @@ config IFCVF

  config MLX5_VDPA
bool "MLX5 VDPA support library for ConnectX devices"
 -  depends on MLX5_CORE
 +  depends on VHOST_IOTLB && MLX5_CORE
default n
>>>
>>> While we are here, can anyone who apply this patch delete the "default n" 
>>> line?
>>> It is by default "n".
> 
> I can do that
> 
>>>
>>> Thanks
>>
>> Hmm other drivers select VHOST_IOTLB, why not do the same?

v1 used select, but Saeed requested use of depends instead because
select can cause problems.

> I can't see another driver doing that. Perhaps I can set dependency on
> VHOST which by itself depends on VHOST_IOTLB?
>>
>>
help
  Support library for Mellanox VDPA drivers. Provides code that is

>>


-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v3 -next] vdpa: mlx5: change Kconfig depends to fix build errors

[Randy Dunlap]

From: Randy Dunlap 

drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so add a dependency
on VHOST to eliminate build errors.

ld: drivers/vdpa/mlx5/core/mr.o: in function `add_direct_chain':
mr.c:(.text+0x106): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x1cf): undefined reference to `vhost_iotlb_itree_next'
ld: mr.c:(.text+0x30d): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x3e8): undefined reference to `vhost_iotlb_itree_next'
ld: drivers/vdpa/mlx5/core/mr.o: in function `_mlx5_vdpa_create_mr':
mr.c:(.text+0x908): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x9e6): undefined reference to `vhost_iotlb_itree_next'
ld: drivers/vdpa/mlx5/core/mr.o: in function `mlx5_vdpa_handle_set_map':
mr.c:(.text+0xf1d): undefined reference to `vhost_iotlb_itree_first'

Signed-off-by: Randy Dunlap 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: virtualization@lists.linux-foundation.org
Cc: Saeed Mahameed 
Cc: Leon Romanovsky 
Cc: net...@vger.kernel.org
---
v2: change from select to depends on VHOST (Saeed)
v3: change to depends on VHOST_IOTLB (Jason)

 drivers/vdpa/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200917.orig/drivers/vdpa/Kconfig
+++ linux-next-20200917/drivers/vdpa/Kconfig
@@ -31,7 +31,7 @@ config IFCVF
 
 config MLX5_VDPA
bool "MLX5 VDPA support library for ConnectX devices"
-   depends on MLX5_CORE
+   depends on VHOST_IOTLB && MLX5_CORE
default n
help
  Support library for Mellanox VDPA drivers. Provides code that is

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v2 -next] vdpa: mlx5: change Kconfig depends to fix build errors

[Randy Dunlap]

From: Randy Dunlap 

drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so add a dependency
on VHOST to eliminate build errors.

ld: drivers/vdpa/mlx5/core/mr.o: in function `add_direct_chain':
mr.c:(.text+0x106): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x1cf): undefined reference to `vhost_iotlb_itree_next'
ld: mr.c:(.text+0x30d): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x3e8): undefined reference to `vhost_iotlb_itree_next'
ld: drivers/vdpa/mlx5/core/mr.o: in function `_mlx5_vdpa_create_mr':
mr.c:(.text+0x908): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x9e6): undefined reference to `vhost_iotlb_itree_next'
ld: drivers/vdpa/mlx5/core/mr.o: in function `mlx5_vdpa_handle_set_map':
mr.c:(.text+0xf1d): undefined reference to `vhost_iotlb_itree_first'

Signed-off-by: Randy Dunlap 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: virtualization@lists.linux-foundation.org
Cc: Saeed Mahameed 
Cc: Leon Romanovsky 
Cc: net...@vger.kernel.org
---
v2: change from select to depends (Saeed)

 drivers/vdpa/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200917.orig/drivers/vdpa/Kconfig
+++ linux-next-20200917/drivers/vdpa/Kconfig
@@ -31,7 +31,7 @@ config IFCVF
 
 config MLX5_VDPA
bool "MLX5 VDPA support library for ConnectX devices"
-   depends on MLX5_CORE
+   depends on VHOST && MLX5_CORE
default n
help
  Support library for Mellanox VDPA drivers. Provides code that is

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH -next] vdpa: mlx5: select VHOST to fix build errors

[Randy Dunlap]

From: Randy Dunlap 

drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so select
VHOST to eliminate build errors.

ld: drivers/vdpa/mlx5/core/mr.o: in function `add_direct_chain':
mr.c:(.text+0x106): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x1cf): undefined reference to `vhost_iotlb_itree_next'
ld: mr.c:(.text+0x30d): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x3e8): undefined reference to `vhost_iotlb_itree_next'
ld: drivers/vdpa/mlx5/core/mr.o: in function `_mlx5_vdpa_create_mr':
mr.c:(.text+0x908): undefined reference to `vhost_iotlb_itree_first'
ld: mr.c:(.text+0x9e6): undefined reference to `vhost_iotlb_itree_next'
ld: drivers/vdpa/mlx5/core/mr.o: in function `mlx5_vdpa_handle_set_map':
mr.c:(.text+0xf1d): undefined reference to `vhost_iotlb_itree_first'

Signed-off-by: Randy Dunlap 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: virtualization@lists.linux-foundation.org
Cc: Saeed Mahameed 
Cc: Leon Romanovsky 
Cc: net...@vger.kernel.org
---
Note: This patch may not be the right thing, but it fixes the build errors.

 drivers/vdpa/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- linux-next-20200917.orig/drivers/vdpa/Kconfig
+++ linux-next-20200917/drivers/vdpa/Kconfig
@@ -32,6 +32,7 @@ config IFCVF
 config MLX5_VDPA
bool "MLX5 VDPA support library for ConnectX devices"
depends on MLX5_CORE
+   select VHOST
default n
help
  Support library for Mellanox VDPA drivers. Provides code that is

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2] i2c: virtio: add a virtio i2c frontend driver

[Randy Dunlap]

On 9/10/20 8:48 PM, Jie Deng wrote:
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 293e7a0..70c8e30 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -21,6 +21,17 @@ config I2C_ALI1535
> This driver can also be built as a module.  If so, the module
> will be called i2c-ali1535.
>  
> +config I2C_VIRTIO
> + tristate "Virtio I2C Adapter"
> + depends on VIRTIO
> + help
> +   If you say yes to this option, support will be included for the virtio
> +   i2c adapter driver. The hardware can be emulated by any device model

  I2C
preferably


> +   software according to the virtio protocol.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called i2c-virtio.
> +
>  config I2C_ALI1563
>   tristate "ALI 1563"
>   depends on PCI


thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vdpa/mlx5: Avoid warnings about shifts on 32-bit platforms

[Randy Dunlap]

On 8/21/20 3:50 PM, Nathan Chancellor wrote:
> Clang warns several times when building for 32-bit ARM along the lines
> of:
> 
> drivers/vdpa/mlx5/net/mlx5_vnet.c:1462:31: warning: shift count >= width
> of type [-Wshift-count-overflow]
> ndev->mvdev.mlx_features |= BIT(VIRTIO_F_VERSION_1);
> ^~~
> 
> This is related to the BIT macro, which uses an unsigned long literal,
> which is 32-bit on ARM so having a shift equal to or larger than 32 will
> cause this warning, such as the above, where VIRTIO_F_VERSION_1 is 32.
> To avoid this, use BIT_ULL, which will be an unsigned long long. This
> matches the size of the features field throughout this driver, which is
> u64 so there should be no functional change.
> 
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1140
> Signed-off-by: Nathan Chancellor 

Reported-by: Randy Dunlap 
on 2020-AUG-10 for i386:
https://lore.kernel.org/linux-next/5a7a0e6d-842a-78f6-aeac-c5b4c27b7...@infradead.org/
:(

Acked-by: Randy Dunlap  # build-tested

Thanks.

> ---
>  drivers/vdpa/mlx5/net/mlx5_vnet.c | 50 +++
>  1 file changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 9df69d5efe8c..70676a6d1691 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -16,19 +16,19 @@
>  #define to_mvdev(__vdev) container_of((__vdev), struct mlx5_vdpa_dev, vdev)
>  
>  #define VALID_FEATURES_MASK  
>   \
> - (BIT(VIRTIO_NET_F_CSUM) | BIT(VIRTIO_NET_F_GUEST_CSUM) |
>\
> -  BIT(VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) | BIT(VIRTIO_NET_F_MTU) | 
> BIT(VIRTIO_NET_F_MAC) |   \
> -  BIT(VIRTIO_NET_F_GUEST_TSO4) | BIT(VIRTIO_NET_F_GUEST_TSO6) |  
>\
> -  BIT(VIRTIO_NET_F_GUEST_ECN) | BIT(VIRTIO_NET_F_GUEST_UFO) | 
> BIT(VIRTIO_NET_F_HOST_TSO4) | \
> -  BIT(VIRTIO_NET_F_HOST_TSO6) | BIT(VIRTIO_NET_F_HOST_ECN) | 
> BIT(VIRTIO_NET_F_HOST_UFO) |   \
> -  BIT(VIRTIO_NET_F_MRG_RXBUF) | BIT(VIRTIO_NET_F_STATUS) | 
> BIT(VIRTIO_NET_F_CTRL_VQ) |  \
> -  BIT(VIRTIO_NET_F_CTRL_RX) | BIT(VIRTIO_NET_F_CTRL_VLAN) |  
>\
> -  BIT(VIRTIO_NET_F_CTRL_RX_EXTRA) | BIT(VIRTIO_NET_F_GUEST_ANNOUNCE) |   
>\
> -  BIT(VIRTIO_NET_F_MQ) | BIT(VIRTIO_NET_F_CTRL_MAC_ADDR) | 
> BIT(VIRTIO_NET_F_HASH_REPORT) |  \
> -  BIT(VIRTIO_NET_F_RSS) | BIT(VIRTIO_NET_F_RSC_EXT) | 
> BIT(VIRTIO_NET_F_STANDBY) |   \
> -  BIT(VIRTIO_NET_F_SPEED_DUPLEX) | BIT(VIRTIO_F_NOTIFY_ON_EMPTY) |   
>\
> -  BIT(VIRTIO_F_ANY_LAYOUT) | BIT(VIRTIO_F_VERSION_1) | 
> BIT(VIRTIO_F_ACCESS_PLATFORM) |  \
> -  BIT(VIRTIO_F_RING_PACKED) | BIT(VIRTIO_F_ORDER_PLATFORM) | 
> BIT(VIRTIO_F_SR_IOV))
> + (BIT_ULL(VIRTIO_NET_F_CSUM) | BIT_ULL(VIRTIO_NET_F_GUEST_CSUM) |
>\
> +  BIT_ULL(VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) | BIT_ULL(VIRTIO_NET_F_MTU) 
> | BIT_ULL(VIRTIO_NET_F_MAC) |   \
> +  BIT_ULL(VIRTIO_NET_F_GUEST_TSO4) | BIT_ULL(VIRTIO_NET_F_GUEST_TSO6) |  
>\
> +  BIT_ULL(VIRTIO_NET_F_GUEST_ECN) | BIT_ULL(VIRTIO_NET_F_GUEST_UFO) | 
> BIT_ULL(VIRTIO_NET_F_HOST_TSO4) | \
> +  BIT_ULL(VIRTIO_NET_F_HOST_TSO6) | BIT_ULL(VIRTIO_NET_F_HOST_ECN) | 
> BIT_ULL(VIRTIO_NET_F_HOST_UFO) |   \
> +  BIT_ULL(VIRTIO_NET_F_MRG_RXBUF) | BIT_ULL(VIRTIO_NET_F_STATUS) | 
> BIT_ULL(VIRTIO_NET_F_CTRL_VQ) |  \
> +  BIT_ULL(VIRTIO_NET_F_CTRL_RX) | BIT_ULL(VIRTIO_NET_F_CTRL_VLAN) |  
>\
> +  BIT_ULL(VIRTIO_NET_F_CTRL_RX_EXTRA) | 
> BIT_ULL(VIRTIO_NET_F_GUEST_ANNOUNCE) |  \
> +  BIT_ULL(VIRTIO_NET_F_MQ) | BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) | 
> BIT_ULL(VIRTIO_NET_F_HASH_REPORT) |  \
> +  BIT_ULL(VIRTIO_NET_F_RSS) | BIT_ULL(VIRTIO_NET_F_RSC_EXT) | 
> BIT_ULL(VIRTIO_NET_F_STANDBY) |   \
> +  BIT_ULL(VIRTIO_NET_F_SPEED_DUPLEX) | BIT_ULL(VIRTIO_F_NOTIFY_ON_EMPTY) 
> |  \
> +  BIT_ULL(VIRTIO_F_ANY_LAYOUT) | BIT_ULL(VIRTIO_F_VERSION_1) | 
> BIT_ULL(VIRTIO_F_ACCESS_PLATFORM) |  \
> +  BIT_ULL(VIRTIO_F_RING_PACKED) | BIT_ULL(VIRTIO_F_ORDER_PLATFORM) | 
> BIT_ULL(VIRTIO_F_SR_IOV))
>  
>  #define VALID_STATUS_MASK
>   \

Re: linux-next: Tree for Aug 10 (drivers/vdpa/mlx5/net)

[Randy Dunlap]

On 8/9/20 9:10 PM, Stephen Rothwell wrote:
> Hi all,
> 


on i386:

Lots (63) of left shift warnings: {not all are shown here}


  CC  drivers/vdpa/mlx5/net/mlx5_vnet.o
In file included from ../include/linux/bits.h:6:0,
 from ../include/linux/bitops.h:5,
 from ../include/linux/kernel.h:12,
 from ../include/linux/vdpa.h:5,
 from ../drivers/vdpa/mlx5/net/mlx5_vnet.c:4:
../drivers/vdpa/mlx5/net/mlx5_vnet.c: In function 'print_features':
../include/vdso/bits.h:7:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
 #define BIT(nr)   (UL(1) << (nr))
  ^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:27:60: note: in expansion of macro 'BIT'
   BIT(VIRTIO_NET_F_MQ) | BIT(VIRTIO_NET_F_CTRL_MAC_ADDR) | 
BIT(VIRTIO_NET_F_HASH_REPORT) |  \
^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro 
'VALID_FEATURES_MASK'
  if (features & ~VALID_FEATURES_MASK)
  ^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
 #define BIT(nr)   (UL(1) << (nr))
  ^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:28:3: note: in expansion of macro 'BIT'
   BIT(VIRTIO_NET_F_RSS) | BIT(VIRTIO_NET_F_RSC_EXT) | 
BIT(VIRTIO_NET_F_STANDBY) |   \
   ^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro 
'VALID_FEATURES_MASK'
  if (features & ~VALID_FEATURES_MASK)
  ^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
 #define BIT(nr)   (UL(1) << (nr))
  ^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:28:27: note: in expansion of macro 'BIT'
   BIT(VIRTIO_NET_F_RSS) | BIT(VIRTIO_NET_F_RSC_EXT) | 
BIT(VIRTIO_NET_F_STANDBY) |   \
   ^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro 
'VALID_FEATURES_MASK'
  if (features & ~VALID_FEATURES_MASK)
  ^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
 #define BIT(nr)   (UL(1) << (nr))
  ^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:28:55: note: in expansion of macro 'BIT'
   BIT(VIRTIO_NET_F_RSS) | BIT(VIRTIO_NET_F_RSC_EXT) | 
BIT(VIRTIO_NET_F_STANDBY) |   \
   ^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro 
'VALID_FEATURES_MASK'
  if (features & ~VALID_FEATURES_MASK)
  ^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
 #define BIT(nr)   (UL(1) << (nr))
  ^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:29:3: note: in expansion of macro 'BIT'
   BIT(VIRTIO_NET_F_SPEED_DUPLEX) | BIT(VIRTIO_F_NOTIFY_ON_EMPTY) | 
 \
   ^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro 
'VALID_FEATURES_MASK'
  if (features & ~VALID_FEATURES_MASK)
  ^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type 
[-Wshift-count-overflow]
 #define BIT(nr)   (UL(1) << (nr))
  ^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:30:30: note: in expansion of macro 'BIT'
   BIT(VIRTIO_F_ANY_LAYOUT) | BIT(VIRTIO_F_VERSION_1) | 
BIT(VIRTIO_F_ACCESS_PLATFORM) |  \
  ^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro 
'VALID_FEATURES_MASK'
  if (features & ~VALID_FEATURES_MASK)
  ^~~



-- 
~Randy
Reported-by: Randy Dunlap 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Apr 15 (vdpa)

[Randy Dunlap]

On 4/14/20 10:22 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20200414:
> 

on x86_64:

ERROR: modpost: "vringh_set_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] 
undefined!
ERROR: modpost: "vringh_init_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] 
undefined!
ERROR: modpost: "vringh_iov_push_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] 
undefined!
ERROR: modpost: "vringh_iov_pull_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] 
undefined!
ERROR: modpost: "vringh_complete_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] 
undefined!
ERROR: modpost: "vringh_getdesc_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] 
undefined!


Full randconfig file is attached.

-- 
~Randy
Reported-by: Randy Dunlap 
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.7.0-rc1 Kernel Configuration
#

#
# Compiler: gcc (SUSE Linux) 7.5.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70500
CONFIG_LD_VERSION=23200
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_UAPI_HEADER_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
CONFIG_WATCH_QUEUE=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_INJECTION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_DEBUGFS=y
# end of IRQ subsystem

CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
# end of Timers subsystem

CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
# CONFIG_TICK_CPU_ACCOUNTING is not set
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
CONFIG_TASKS_RCU=y
# end of RCU Subsystem

CONFIG_IKCONFIG=y
CONFIG_IKHEADERS=y
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y

#
# Scheduler features
#
# end of Scheduler features

CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CC_HAS_INT128=y
CONFIG_ARCH_SUPPORTS_INT128=y
# CONFIG_CGROUPS is not set
# CONFIG_NAMESPACES is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_BOOT_CONFIG=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
# CONFIG_POSIX_TIMERS is not set
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_PCSPKR_PLATFORM is not set
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
# CONFIG_EVENTFD is not set
# CONFIG_SHMEM is not set
# CONFIG_AIO is not set
CONFIG_IO_URING=y
# CONFIG_ADVISE_SYSCALLS is not set
CONFIG_HAVE_ARCH_USERFAULTFD_WP=y
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT

Re: mmotm 2020-03-30-18-46 uploaded (VDPA + vhost)

[Randy Dunlap]

On 3/31/20 12:22 PM, Michael S. Tsirkin wrote:
> On Tue, Mar 31, 2020 at 11:42:47AM -0700, Randy Dunlap wrote:
>> On 3/31/20 11:37 AM, Michael S. Tsirkin wrote:
>>> On Tue, Mar 31, 2020 at 11:27:54AM -0700, Randy Dunlap wrote:
>>>> On 3/30/20 6:47 PM, a...@linux-foundation.org wrote:
>>>>> The mm-of-the-moment snapshot 2020-03-30-18-46 has been uploaded to
>>>>>
>>>>>http://www.ozlabs.org/~akpm/mmotm/
>>>>>
>>>>> mmotm-readme.txt says
>>>>>
>>>>> README for mm-of-the-moment:
>>>>>
>>>>> http://www.ozlabs.org/~akpm/mmotm/
>>>>>
>>>>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>>>>> more than once a week.
>>>>>
>>>>> You will need quilt to apply these patches to the latest Linus release 
>>>>> (5.x
>>>>> or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>>>>> http://ozlabs.org/~akpm/mmotm/series
>>>>>
>>>>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>>>>> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
>>>>> followed by the base kernel version against which this patch series is to
>>>>> be applied.
>>>>>
>>>>> This tree is partially included in linux-next.  To see which patches are
>>>>> included in linux-next, consult the `series' file.  Only the patches
>>>>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>>>>> linux-next.
>>>>>
>>>>>
>>>>> A full copy of the full kernel tree with the linux-next and mmotm patches
>>>>> already applied is available through git within an hour of the mmotm
>>>>> release.  Individual mmotm releases are tagged.  The master branch always
>>>>> points to the latest release, so it's constantly rebasing.
>>>>>
>>>>>   https://github.com/hnaz/linux-mm
>>>>
>>>> on i386:
>>>>
>>>> ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_init':
>>>> vdpa.c:(.init.text+0x52): undefined reference to `__vdpa_register_driver'
>>>> ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_exit':
>>>> vdpa.c:(.exit.text+0x14): undefined reference to `vdpa_unregister_driver'
>>>>
>>>>
>>>>
>>>> drivers/virtio/vdpa/ is not being built. (confusing!)
>>>>
>>>> CONFIG_VIRTIO=m
>>>> # CONFIG_VIRTIO_MENU is not set
>>>> CONFIG_VDPA=y
>>>
>>> Hmm. OK. Can't figure it out. CONFIG_VDPA is set why isn't
>>> drivers/virtio/vdpa/ built?
>>> we have:
>>>
>>
>> Ack.  Hopefully Yamada-san can tell us what is happening here.
> 
> OK I pushed a fix (moving the vdpa subsystem up a level) and pushed into
> my tree, refs/heads/next .  Seems to build fine now, but I'd appreciate
> it if you can give it a spin.

This now builds successfully on linux-next of 20200401.

Thanks.

-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vdpa: move to drivers/vdpa

[Randy Dunlap]

On 3/31/20 12:19 PM, Michael S. Tsirkin wrote:
> We have both vhost and virtio drivers that depend on vdpa.
> It's easier to locate it at a top level directory otherwise
> we run into issues e.g. if vhost is built-in but virtio
> is modular.  Let's just move it up a level.
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Michael S. Tsirkin 
> ---
> 
> Randy I'd say the issue you are reporting (vhost=y, virtio=m)
> is esoteric enough not to require a rebase for this.
> So I'd just apply this on top.
> Do you agree?

Sure, looks fine from just reading it.
I haven't had a chance to test it yet.

Thanks.

>  MAINTAINERS   | 1 +
>  drivers/Kconfig   | 2 ++
>  drivers/Makefile  | 1 +
>  drivers/{virtio => }/vdpa/Kconfig | 0
>  drivers/{virtio => }/vdpa/Makefile| 0
>  drivers/{virtio => }/vdpa/ifcvf/Makefile  | 0
>  drivers/{virtio => }/vdpa/ifcvf/ifcvf_base.c  | 0
>  drivers/{virtio => }/vdpa/ifcvf/ifcvf_base.h  | 0
>  drivers/{virtio => }/vdpa/ifcvf/ifcvf_main.c  | 0
>  drivers/{virtio => }/vdpa/vdpa.c  | 0
>  drivers/{virtio => }/vdpa/vdpa_sim/Makefile   | 0
>  drivers/{virtio => }/vdpa/vdpa_sim/vdpa_sim.c | 0
>  drivers/virtio/Kconfig| 2 --
>  13 files changed, 4 insertions(+), 2 deletions(-)
>  rename drivers/{virtio => }/vdpa/Kconfig (100%)
>  rename drivers/{virtio => }/vdpa/Makefile (100%)
>  rename drivers/{virtio => }/vdpa/ifcvf/Makefile (100%)
>  rename drivers/{virtio => }/vdpa/ifcvf/ifcvf_base.c (100%)
>  rename drivers/{virtio => }/vdpa/ifcvf/ifcvf_base.h (100%)
>  rename drivers/{virtio => }/vdpa/ifcvf/ifcvf_main.c (100%)
>  rename drivers/{virtio => }/vdpa/vdpa.c (100%)
>  rename drivers/{virtio => }/vdpa/vdpa_sim/Makefile (100%)
>  rename drivers/{virtio => }/vdpa/vdpa_sim/vdpa_sim.c (100%)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 70c47bc55343..7cfa55c765fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17695,6 +17695,7 @@ L:virtualization@lists.linux-foundation.org
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/virtio/
>  F:   drivers/virtio/
> +F:   drivers/vdpa/
>  F:   tools/virtio/
>  F:   drivers/net/virtio_net.c
>  F:   drivers/block/virtio_blk.c
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 7a6d8b2b68b4..ac23d520e916 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -138,6 +138,8 @@ source "drivers/virt/Kconfig"
>  
>  source "drivers/virtio/Kconfig"
>  
> +source "drivers/vdpa/Kconfig"
> +
>  source "drivers/vhost/Kconfig"
>  
>  source "drivers/hv/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 31cf17dee252..21688f3b1588 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_DMADEVICES)+= dma/
>  obj-y+= soc/
>  
>  obj-$(CONFIG_VIRTIO) += virtio/
> +obj-$(CONFIG_VDPA)   += vdpa/
>  obj-$(CONFIG_XEN)+= xen/
>  
>  # regulators early, since some subsystems rely on them to initialize
> diff --git a/drivers/virtio/vdpa/Kconfig b/drivers/vdpa/Kconfig
> similarity index 100%
> rename from drivers/virtio/vdpa/Kconfig
> rename to drivers/vdpa/Kconfig
> diff --git a/drivers/virtio/vdpa/Makefile b/drivers/vdpa/Makefile
> similarity index 100%
> rename from drivers/virtio/vdpa/Makefile
> rename to drivers/vdpa/Makefile
> diff --git a/drivers/virtio/vdpa/ifcvf/Makefile b/drivers/vdpa/ifcvf/Makefile
> similarity index 100%
> rename from drivers/virtio/vdpa/ifcvf/Makefile
> rename to drivers/vdpa/ifcvf/Makefile
> diff --git a/drivers/virtio/vdpa/ifcvf/ifcvf_base.c 
> b/drivers/vdpa/ifcvf/ifcvf_base.c
> similarity index 100%
> rename from drivers/virtio/vdpa/ifcvf/ifcvf_base.c
> rename to drivers/vdpa/ifcvf/ifcvf_base.c
> diff --git a/drivers/virtio/vdpa/ifcvf/ifcvf_base.h 
> b/drivers/vdpa/ifcvf/ifcvf_base.h
> similarity index 100%
> rename from drivers/virtio/vdpa/ifcvf/ifcvf_base.h
> rename to drivers/vdpa/ifcvf/ifcvf_base.h
> diff --git a/drivers/virtio/vdpa/ifcvf/ifcvf_main.c 
> b/drivers/vdpa/ifcvf/ifcvf_main.c
> similarity index 100%
> rename from drivers/virtio/vdpa/ifcvf/ifcvf_main.c
> rename to drivers/vdpa/ifcvf/ifcvf_main.c
> diff --git a/drivers/virtio/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> similarity index 100%
> rename from drivers/virtio/vdpa/vdpa.c
> rename to drivers/vdpa/vdpa.c
> diff --git a/drivers/virtio/vdpa/vdpa_sim/Makefile 
> b/drivers/vdpa/vdpa_sim/Makefile
> similarity index 100%
> rename from drivers/virtio/vdpa/vdpa_sim/Mak

Re: mmotm 2020-03-30-18-46 uploaded (VDPA + vhost)

[Randy Dunlap]

On 3/31/20 11:37 AM, Michael S. Tsirkin wrote:
> On Tue, Mar 31, 2020 at 11:27:54AM -0700, Randy Dunlap wrote:
>> On 3/30/20 6:47 PM, a...@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2020-03-30-18-46 has been uploaded to
>>>
>>>http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> mmotm-readme.txt says
>>>
>>> README for mm-of-the-moment:
>>>
>>> http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>>> more than once a week.
>>>
>>> You will need quilt to apply these patches to the latest Linus release (5.x
>>> or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>>> http://ozlabs.org/~akpm/mmotm/series
>>>
>>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>>> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
>>> followed by the base kernel version against which this patch series is to
>>> be applied.
>>>
>>> This tree is partially included in linux-next.  To see which patches are
>>> included in linux-next, consult the `series' file.  Only the patches
>>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>>> linux-next.
>>>
>>>
>>> A full copy of the full kernel tree with the linux-next and mmotm patches
>>> already applied is available through git within an hour of the mmotm
>>> release.  Individual mmotm releases are tagged.  The master branch always
>>> points to the latest release, so it's constantly rebasing.
>>>
>>> https://github.com/hnaz/linux-mm
>>
>> on i386:
>>
>> ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_init':
>> vdpa.c:(.init.text+0x52): undefined reference to `__vdpa_register_driver'
>> ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_exit':
>> vdpa.c:(.exit.text+0x14): undefined reference to `vdpa_unregister_driver'
>>
>>
>>
>> drivers/virtio/vdpa/ is not being built. (confusing!)
>>
>> CONFIG_VIRTIO=m
>> # CONFIG_VIRTIO_MENU is not set
>> CONFIG_VDPA=y
> 
> Hmm. OK. Can't figure it out. CONFIG_VDPA is set why isn't
> drivers/virtio/vdpa/ built?
> we have:
> 

Ack.  Hopefully Yamada-san can tell us what is happening here.

> 
> obj-$(CONFIG_VDPA) += vdpa/
> 
> and under that:
> 
> obj-$(CONFIG_VDPA) += vdpa.o
> 
> 
>> CONFIG_VDPA_MENU=y
>> # CONFIG_VDPA_SIM is not set
>> CONFIG_VHOST_IOTLB=y
>> CONFIG_VHOST_RING=m
>> CONFIG_VHOST=y
>> CONFIG_VHOST_SCSI=m
>> CONFIG_VHOST_VDPA=y
>>
>> Full randconfig file is attached.
>>
>> (This same build failure happens with today's linux-next, Mar. 31.)
>>
>> @Yamada-san:  Is this a kbuild problem (or feature)?
>>
>> -- 
>> ~Randy
>> Reported-by: Randy Dunlap 
> 


-- 
~Randy
Reported-by: Randy Dunlap 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vhost: make CONFIG_VHOST depend on CONFIG_EVENTFD

[Randy Dunlap]

On 3/30/20 7:29 PM, Jason Wang wrote:
> After commit ec9d8449a99b ("vhost: refine vhost and vringh kconfig"),
> CONFIG_VHOST could be enabled independently. This means we need make
> CONFIG_VHOST depend on CONFIG_EVENTFD, otherwise we break compiling
> without CONFIG_EVENTFD.
> 
> Reported-by: Randy Dunlap 
> Fixes: ec9d8449a99b ("vhost: refine vhost and vringh kconfig")
> Signed-off-by: Jason Wang 
> ---
>  drivers/vhost/Kconfig | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Acked-by: Randy Dunlap  # build-tested

thanks.

-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Mar 30 (vhost)

[Randy Dunlap]

On 3/30/20 2:43 AM, Stephen Rothwell wrote:
> Hi all,
> 
> The merge window has opened, so please do not add any material for the
> next release into your linux-next included trees/branches until after
> the merge window closes.
> 
> Changes since 20200327:
> 
> The vhost tree gained a conflict against the kvm-arm tree.
> 

(note: today's linux-next is on 5.6-rc7.)

on x86_64:

# CONFIG_EVENTFD is not set

../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]
   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
   eventfp = f.fd == -1 ? NULL : eventfd_fget(f.fd);
   ^

-- 
~Randy
Reported-by: Randy Dunlap 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V3 5/5] vdpasim: vDPA device simulator

[Randy Dunlap]

On 2/19/20 7:56 PM, Jason Wang wrote:
> diff --git a/drivers/virtio/vdpa/Kconfig b/drivers/virtio/vdpa/Kconfig
> index 7a99170e6c30..e3656b722654 100644
> --- a/drivers/virtio/vdpa/Kconfig
> +++ b/drivers/virtio/vdpa/Kconfig
> @@ -7,3 +7,21 @@ config VDPA
>datapath which complies with virtio specifications with
>vendor specific control path.
>  
> +menuconfig VDPA_MENU
> + bool "VDPA drivers"
> + default n
> +
> +if VDPA_MENU
> +
> +config VDPA_SIM
> + tristate "vDPA device simulator"
> +select VDPA
> +depends on RUNTIME_TESTING_MENU
> +default n
> +help
> +  vDPA networking device simulator which loop TX traffic back
> +  to RX. This device is used for testing, prototyping and
> +  development of vDPA.
> +
> +endif # VDPA_MENU
> +

Use 1 tab for indentation for tristate/select/depends/default/help,
and then 1 tab + 2 spaces for help text.

-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V3 4/5] virtio: introduce a vDPA based transport

[Randy Dunlap]

On 2/19/20 7:56 PM, Jason Wang wrote:
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 9c4fdb64d9ac..0df3676b0f4f 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -43,6 +43,19 @@ config VIRTIO_PCI_LEGACY
>  
> If unsure, say Y.
>  
> +config VIRTIO_VDPA
> + tristate "vDPA driver for virtio devices"
> +select VDPA
> +select VIRTIO
> + help
> +   This driver provides support for virtio based paravirtual
> +   device driver over vDPA bus. For this to be useful, you need
> +   an appropriate vDPA device implementation that operates on a
> +  physical device to allow the datapath of virtio to be
> +   offloaded to hardware.
> +
> +   If unsure, say M.
> +

Please use tabs consistently for indentation, not spaces,
except in the Kconfig help text, which should be 1 tab + 2 spaces.

>  config VIRTIO_PMEM
>   tristate "Support for virtio pmem driver"
>   depends on VIRTIO


-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V3 3/5] vDPA: introduce vDPA bus

[Randy Dunlap]

On 2/19/20 7:56 PM, Jason Wang wrote:
> diff --git a/drivers/virtio/vdpa/Kconfig b/drivers/virtio/vdpa/Kconfig
> new file mode 100644
> index ..7a99170e6c30
> --- /dev/null
> +++ b/drivers/virtio/vdpa/Kconfig
> @@ -0,0 +1,9 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config VDPA
> + tristate
> +default m

Don't add drivers that are enabled by default, unless they are required
for a system to boot.

And anything that wants VDPA should just select it, so this is not needed.

> +help
> +  Enable this module to support vDPA device that uses a
> +  datapath which complies with virtio specifications with
> +  vendor specific control path.
> +

thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V3 1/5] vhost: factor out IOTLB

[Randy Dunlap]

On 2/19/20 7:56 PM, Jason Wang wrote:
> This patch factors out IOTLB into a dedicated module in order to be
> reused by other modules like vringh. User may choose to enable the
> automatic retiring by specifying VHOST_IOTLB_FLAG_RETIRE flag to fit
> for the case of vhost device IOTLB implementation.
> 
> Signed-off-by: Jason Wang 
> ---
>  MAINTAINERS |   1 +
>  drivers/vhost/Kconfig   |   7 ++
>  drivers/vhost/Makefile  |   2 +
>  drivers/vhost/net.c |   2 +-
>  drivers/vhost/vhost.c   | 221 +++-
>  drivers/vhost/vhost.h   |  36 ++
>  drivers/vhost/vhost_iotlb.c | 171 
>  include/linux/vhost_iotlb.h |  45 
>  8 files changed, 304 insertions(+), 181 deletions(-)
>  create mode 100644 drivers/vhost/vhost_iotlb.c
>  create mode 100644 include/linux/vhost_iotlb.h
> 

Hi,
Sorry if you have gone over this previously:

> diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> index 3d03ccbd1adc..eef634ff9a6e 100644
> --- a/drivers/vhost/Kconfig
> +++ b/drivers/vhost/Kconfig
> @@ -36,6 +36,7 @@ config VHOST_VSOCK
>  
>  config VHOST
>   tristate
> + select VHOST_IOTLB
>   ---help---
> This option is selected by any driver which needs to access
> the core of vhost.
> @@ -54,3 +55,9 @@ config VHOST_CROSS_ENDIAN_LEGACY
> adds some overhead, it is disabled by default.
>  
> If unsure, say "N".
> +
> +config VHOST_IOTLB
> + tristate
> + default m

"default m" should not be needed. Just make whatever needs it select it.

> + help
> +   Generic IOTLB implementation for vhost and vringh.


-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vhost: introduce vDPA based backend

[Randy Dunlap]

On 1/30/20 7:56 PM, Randy Dunlap wrote:
> Hi,
> 
> On 1/30/20 7:36 PM, Tiwei Bie wrote:
>> diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
>> index f21c45aa5e07..13e6a94d0243 100644
>> --- a/drivers/vhost/Kconfig
>> +++ b/drivers/vhost/Kconfig
>> @@ -34,6 +34,18 @@ config VHOST_VSOCK
>>  To compile this driver as a module, choose M here: the module will be 
>> called
>>  vhost_vsock.
>>  
>> +config VHOST_VDPA
>> +tristate "Vhost driver for vDPA based backend"

oops, missed this one:
   vDPA-based

>> +depends on EVENTFD && VDPA
>> +select VHOST
>> +default n
>> +---help---
>> +This kernel module can be loaded in host kernel to accelerate
>> +guest virtio devices with the vDPA based backends.
> 
> vDPA-based
> 
>> +
>> +To compile this driver as a module, choose M here: the module
>> +will be called vhost_vdpa.
>> +
> 
> The preferred Kconfig style nowadays is
> (a) use "help" instead of "---help---"
> (b) indent the help text with one tab + 2 spaces
> 
> and don't use "default n" since that is already the default.
> 
>>  config VHOST
>>  tristate
>>  depends on VHOST_IOTLB
> 
> thanks.
> 


-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vhost: introduce vDPA based backend

[Randy Dunlap]

Hi,

On 1/30/20 7:36 PM, Tiwei Bie wrote:
> diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> index f21c45aa5e07..13e6a94d0243 100644
> --- a/drivers/vhost/Kconfig
> +++ b/drivers/vhost/Kconfig
> @@ -34,6 +34,18 @@ config VHOST_VSOCK
>   To compile this driver as a module, choose M here: the module will be 
> called
>   vhost_vsock.
>  
> +config VHOST_VDPA
> + tristate "Vhost driver for vDPA based backend"
> + depends on EVENTFD && VDPA
> + select VHOST
> + default n
> + ---help---
> + This kernel module can be loaded in host kernel to accelerate
> + guest virtio devices with the vDPA based backends.

  vDPA-based

> +
> + To compile this driver as a module, choose M here: the module
> + will be called vhost_vdpa.
> +

The preferred Kconfig style nowadays is
(a) use "help" instead of "---help---"
(b) indent the help text with one tab + 2 spaces

and don't use "default n" since that is already the default.

>  config VHOST
>   tristate
>  depends on VHOST_IOTLB

thanks.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 3/5] vDPA: introduce vDPA bus

[Randy Dunlap]

On 1/16/20 4:42 AM, Jason Wang wrote:
> diff --git a/drivers/virtio/vdpa/Kconfig b/drivers/virtio/vdpa/Kconfig
> new file mode 100644
> index ..3032727b4d98
> --- /dev/null
> +++ b/drivers/virtio/vdpa/Kconfig
> @@ -0,0 +1,9 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config VDPA
> + tristate
> +default n
> +help
> +  Enable this module to support vDPA device that uses a

devices

> +  datapath which complies with virtio specifications with
> +  vendor specific control path.
> +

Use tab + 2 spaces for Kconfig indentation.

-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/5] vhost: factor out IOTLB

[Randy Dunlap]

On 1/16/20 4:42 AM, Jason Wang wrote:
> diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> index 3d03ccbd1adc..f21c45aa5e07 100644
> --- a/drivers/vhost/Kconfig
> +++ b/drivers/vhost/Kconfig
> @@ -36,6 +36,7 @@ config VHOST_VSOCK
>  
>  config VHOST
>   tristate
> +depends on VHOST_IOTLB
>   ---help---
> This option is selected by any driver which needs to access
> the core of vhost.
> @@ -54,3 +55,9 @@ config VHOST_CROSS_ENDIAN_LEGACY
> adds some overhead, it is disabled by default.
>  
> If unsure, say "N".
> +
> +config VHOST_IOTLB
> + tristate
> +default m
> +help
> +  Generic IOTLB implementation for vhost and vringh.

Use tab + 2 spaces for Kconfig indentation.

-- 
~Randy
Reported-by: Randy Dunlap 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 5/5] vdpasim: vDPA device simulator

[Randy Dunlap]

On 1/16/20 4:42 AM, Jason Wang wrote:
> diff --git a/drivers/virtio/vdpa/Kconfig b/drivers/virtio/vdpa/Kconfig
> index 3032727b4d98..12ec25d48423 100644
> --- a/drivers/virtio/vdpa/Kconfig
> +++ b/drivers/virtio/vdpa/Kconfig
> @@ -7,3 +7,20 @@ config VDPA
>datapath which complies with virtio specifications with
>vendor specific control path.
>  
> +menuconfig VDPA_MENU
> + bool "VDPA drivers"
> + default n
> +
> +if VDPA_MENU
> +
> +config VDPA_SIM
> + tristate "vDPA device simulator"
> +select VDPA
> +default n
> +help
> +  vDPA networking device simulator which loop TX traffic back

loops

> +  to RX. This device is used for testing, prototyping and
> +  development of vDPA.
> +
> +endif # VDPA_MENU

Most lines above use spaces for indentation, while they should use
tab + 2 spaces.

-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 4/5] virtio: introduce a vDPA based transport

[Randy Dunlap]

Hi,

On 1/16/20 4:42 AM, Jason Wang wrote:
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 9c4fdb64d9ac..b4276999d17d 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -43,6 +43,19 @@ config VIRTIO_PCI_LEGACY
>  
> If unsure, say Y.
>  
> +config VIRTIO_VDPA
> + tristate "vDPA driver for virtio devices"
> + depends on VDPA && VIRTIO
> + default n
> + help
> +   This driver provides support for virtio based paravirtual

   virtio-based

> +   device driver over vDPA bus. For this to be useful, you need
> +   an appropriate vDPA device implementation that operates on a
> +  physical device to allow the datapath of virtio to be

use tab + 2 spaces above for indentation, not lots of spaces.

> +   offloaded to hardware.
> +
> +   If unsure, say M.
> +
>  config VIRTIO_PMEM
>   tristate "Support for virtio pmem driver"
>   depends on VIRTIO


-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH V9 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework

[Randy Dunlap]

On 11/5/19 11:05 PM, Jason Wang wrote:
> diff --git a/samples/Kconfig b/samples/Kconfig
> index c8dacb4dda80..13a2443e18e0 100644
> --- a/samples/Kconfig
> +++ b/samples/Kconfig
> @@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY
> mediated device.  It is a simple framebuffer and supports
> the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
>  
> +config SAMPLE_VIRTIO_MDEV_NET
> + tristate "Build VIRTIO net example mediated device sample code -- 
> loadable modules only"
> + depends on VIRTIO_MDEV && VHOST_RING && m
> + help
> +   Build a networking sample device for use as a virtio
> +   mediated device. The device coopreates with virtio-mdev bus

typo here:
  cooperates

> +   driver to present an virtio ethernet driver for
> +   kernel. It simply loopbacks all packets from its TX
> +   virtqueue to its RX virtqueue.
> +
>  config SAMPLE_VFIO_MDEV_MDPY_FB
>   tristate "Build VFIO mdpy example guest fbdev driver -- loadable module 
> only"
>   depends on FB && m

ciao.
-- 
~Randy

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v9 2/7] virtio-pmem: Add virtio pmem driver

[Randy Dunlap]

On 5/14/19 7:54 AM, Pankaj Gupta wrote:
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 35897649c24f..94bad084ebab 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -42,6 +42,17 @@ config VIRTIO_PCI_LEGACY
>  
> If unsure, say Y.
>  
> +config VIRTIO_PMEM
> + tristate "Support for virtio pmem driver"
> + depends on VIRTIO
> + depends on LIBNVDIMM
> + help
> + This driver provides access to virtio-pmem devices, storage devices
> + that are mapped into the physical address space - similar to NVDIMMs
> +  - with a virtio-based flushing interface.
> +
> + If unsure, say M.


from Documentation/process/coding-style.rst:
"Lines under a ``config`` definition
are indented with one tab, while help text is indented an additional two
spaces."

> +
>  config VIRTIO_BALLOON
>   tristate "Virtio balloon driver"
>   depends on VIRTIO

thanks.
-- 
~Randy

Re: [PATCH] VMCI: Use BIT() macro for bit definitions

[Randy Dunlap]

On 3/11/19 3:09 PM, Vishnu DASA wrote:
> No functional changes, cleanup only.
> 
> Reviewed-by: Adit Ranadive 
> Reviewed-by: Jorgen Hansen 
> Signed-off-by: Vishnu Dasa 
> ---
>  include/linux/vmw_vmci_defs.h | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 

Now this header file needs to #include 
or  for the BIT() macro.

Do the users of this header file build cleanly anyway?
Even if so, we prefer not to depend on implicit or accidental header
file inclusions that may change in the future.

> diff --git a/include/linux/vmw_vmci_defs.h b/include/linux/vmw_vmci_defs.h
> index eaa1e762bf06..007e28053da8 100644
> --- a/include/linux/vmw_vmci_defs.h
> +++ b/include/linux/vmw_vmci_defs.h
> @@ -33,27 +33,27 @@
>  #define VMCI_MAX_DEVICES 1
>  
>  /* Status register bits. */
> -#define VMCI_STATUS_INT_ON 0x1
> +#define VMCI_STATUS_INT_ON BIT(0)
>  
>  /* Control register bits. */
> -#define VMCI_CONTROL_RESET0x1
> -#define VMCI_CONTROL_INT_ENABLE   0x2
> -#define VMCI_CONTROL_INT_DISABLE  0x4
> +#define VMCI_CONTROL_RESETBIT(0)
> +#define VMCI_CONTROL_INT_ENABLE   BIT(1)
> +#define VMCI_CONTROL_INT_DISABLE  BIT(2)
>  
>  /* Capabilities register bits. */
> -#define VMCI_CAPS_HYPERCALL 0x1
> -#define VMCI_CAPS_GUESTCALL 0x2
> -#define VMCI_CAPS_DATAGRAM  0x4
> -#define VMCI_CAPS_NOTIFICATIONS 0x8
> -#define VMCI_CAPS_PPN64 0x10
> +#define VMCI_CAPS_HYPERCALL BIT(0)
> +#define VMCI_CAPS_GUESTCALL BIT(1)
> +#define VMCI_CAPS_DATAGRAM  BIT(2)
> +#define VMCI_CAPS_NOTIFICATIONS BIT(3)
> +#define VMCI_CAPS_PPN64 BIT(4)
>  
>  /* Interrupt Cause register bits. */
> -#define VMCI_ICR_DATAGRAM  0x1
> -#define VMCI_ICR_NOTIFICATION  0x2
> +#define VMCI_ICR_DATAGRAM  BIT(0)
> +#define VMCI_ICR_NOTIFICATION  BIT(1)
>  
>  /* Interrupt Mask register bits. */
> -#define VMCI_IMR_DATAGRAM  0x1
> -#define VMCI_IMR_NOTIFICATION  0x2
> +#define VMCI_IMR_DATAGRAM  BIT(0)
> +#define VMCI_IMR_NOTIFICATION  BIT(1)
>  
>  /* Maximum MSI/MSI-X interrupt vectors in the device. */
>  #define VMCI_MAX_INTRS 2
> @@ -463,9 +463,9 @@ struct vmci_datagram {
>   * datagram callback is invoked in a delayed context (not interrupt context).
>   */
>  #define VMCI_FLAG_DG_NONE  0
> -#define VMCI_FLAG_WELLKNOWN_DG_HND 0x1
> -#define VMCI_FLAG_ANYCID_DG_HND0x2
> -#define VMCI_FLAG_DG_DELAYED_CB0x4
> +#define VMCI_FLAG_WELLKNOWN_DG_HND BIT(0)
> +#define VMCI_FLAG_ANYCID_DG_HNDBIT(1)
> +#define VMCI_FLAG_DG_DELAYED_CBBIT(2)
>  
>  /*
>   * Maximum supported size of a VMCI datagram for routable datagrams.
> @@ -694,7 +694,7 @@ struct vmci_qp_detach_msg {
>  };
>  
>  /* VMCI Doorbell API. */
> -#define VMCI_FLAG_DELAYED_CB 0x01
> +#define VMCI_FLAG_DELAYED_CB BIT(0)
>  
>  typedef void (*vmci_callback) (void *client_data);
>  
> 


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/3] [RFC V3] KVM: X86: Memory ROE documentation

[Randy Dunlap]

On 07/19/2018 02:38 PM, Ahmed Abd El Mawgood wrote:

>  Documentation/virtual/kvm/hypercalls.txt | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/hypercalls.txt 
> b/Documentation/virtual/kvm/hypercalls.txt
> index a890529c63ed..a9db68adb7c9 100644
> --- a/Documentation/virtual/kvm/hypercalls.txt
> +++ b/Documentation/virtual/kvm/hypercalls.txt
> @@ -121,3 +121,17 @@ compute the CLOCK_REALTIME for its clock, at the same 
> instant.
>  
>  Returns KVM_EOPNOTSUPP if the host does not use TSC clocksource,
>  or if clock type is different than KVM_CLOCK_PAIRING_WALLCLOCK.
> +
> +7. KVM_HC_HMROE
> +
> +Architecture: x86
> +Status: active
> +Purpose: Hypercall used to apply Read-Only Enforcement to guest pages
> +Usage:
> + a0: start address of page that should be protected.

Is this done one page per call?  No grouping, no multiple pages?

> +
> +This hypercall lets a guest kernel to have part of its read/write memory

  lets a guest kernel have part of

> +converted into read-only.  This action is irreversible. KVM_HC_HMROE can
> +not be triggered from guest Ring 3 (user mode). The reason is that user
> +mode malicious software can make use of it enforce read only protection on

   make use of it to enforce

> +an arbitrary memory page thus crashing the kernel.
> 


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 3/3] [RFC V3] KVM: X86: Adding skeleton for Memory ROE

[Randy Dunlap]

On 07/19/2018 02:38 PM, Ahmed Abd El Mawgood wrote:
> This patch introduces a hypercall implemented for X86 that can assist
> against subset of kernel rootkits, it works by place readonly protection in
> shadow PTE. The end result protection is also kept in a bitmap for each
> kvm_memory_slot and is used as reference when updating SPTEs. The whole
> goal is to protect the guest kernel static data from modification if
> attacker is running from guest ring 0, for this reason there is no
> hypercall to revert effect of Memory ROE hypercall. This patch doesn't
> implement integrity check on guest TLB so obvious attack on the current
> implementation will involve guest virtual address -> guest physical
> address remapping, but there are plans to fix that.
> 
> Signed-off-by: Ahmed Abd El Mawgood 
> ---

> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 92fd433c50b9..8ae822a8dc7a 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -96,6 +96,13 @@ config KVM_MMU_AUDIT
>This option adds a R/W kVM module parameter 'mmu_audit', which allows
>auditing of KVM MMU events at runtime.
>  
> +config KVM_MROE
> + bool "Hypercall Memory Read-Only Enforcement"
> + depends on KVM && X86
> + help
> + This option add KVM_HC_HMROE hypercall to kvm which as hardening

adds   to kvm as a hardening   (???)


> + mechanism to protect memory pages from being edited.
> +
>  # OK, it's a little counter-intuitive to do this, but it puts it neatly under
>  # the virtualization menu.
>  source drivers/vhost/Kconfig


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 23/27] x86/modules: Adapt module loading for PIE support

[Randy Dunlap]

On 05/23/2018 03:01 PM, Thomas Garnier wrote:
> On Wed, May 23, 2018 at 2:27 PM Randy Dunlap <rdun...@infradead.org> wrote:
> 
>> Hi,
> 
>> (for several patches in this series:)
>> The commit message is confusing.  See below.
> 
> Thanks for the edits, I will change the different commit messages.
> 
> 
> 
>> On 05/23/2018 12:54 PM, Thomas Garnier wrote:
>>> Adapt module loading to support PIE relocations. Generate dynamic GOT if
>>> a symbol requires it but no entry exist in the kernel GOT.
> 
>>  exists
> 
>>>
>>> Position Independent Executable (PIE) support will allow to extended the
> 
>>  will allow us to extend
> the
> 
>>> KASLR randomization range below the -2G memory limit.
> 
>> Does that say "below th negative 2G memory limit"?
>> I don't get it.
> 
> Yes, below 0x8000 basically. I think I will just say that.

Yes, please, that's much better.

> 
> 
>>>
>>> Signed-off-by: Thomas Garnier <thgar...@google.com>
>>> ---
>>>  arch/x86/Makefile   |   4 +
>>>  arch/x86/include/asm/module.h   |  11 ++
>>>  arch/x86/include/asm/sections.h |   4 +
>>>  arch/x86/kernel/module.c| 181 +++-
>>>  arch/x86/kernel/module.lds  |   3 +
>>>  5 files changed, 198 insertions(+), 5 deletions(-)
>>>  create mode 100644 arch/x86/kernel/module.lds
> 
> 
>> Thanks,
>> --
>> ~Randy
> 
> 
> 


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 23/27] x86/modules: Adapt module loading for PIE support

[Randy Dunlap]

Hi,

(for several patches in this series:)
The commit message is confusing.  See below.


On 05/23/2018 12:54 PM, Thomas Garnier wrote:
> Adapt module loading to support PIE relocations. Generate dynamic GOT if
> a symbol requires it but no entry exist in the kernel GOT.

exists

> 
> Position Independent Executable (PIE) support will allow to extended the

will allow us to extend the

> KASLR randomization range below the -2G memory limit.

Does that say "below th negative 2G memory limit"?
I don't get it.


> 
> Signed-off-by: Thomas Garnier 
> ---
>  arch/x86/Makefile   |   4 +
>  arch/x86/include/asm/module.h   |  11 ++
>  arch/x86/include/asm/sections.h |   4 +
>  arch/x86/kernel/module.c| 181 +++-
>  arch/x86/kernel/module.lds  |   3 +
>  5 files changed, 198 insertions(+), 5 deletions(-)
>  create mode 100644 arch/x86/kernel/module.lds


Thanks,
-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 16/27] compiler: Option to add PROVIDE_HIDDEN replacement for weak symbols

[Randy Dunlap]

On 05/23/2018 12:54 PM, Thomas Garnier wrote:
> Provide an option to have a PROVIDE_HIDDEN (linker script) entry for
> each weak symbol. This option solve an error in x86_64 where the linker

solves

> optimizes pie generate code to be non-pie because --emit-relocs was used

generated

> instead of -pie (to reduce dynamic relocations).
> 
> Signed-off-by: Thomas Garnier 
> ---
>  init/Kconfig|  7 +++
>  scripts/link-vmlinux.sh | 14 ++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 0fc3a58d9f2f..2866cca86b4a 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1954,6 +1954,13 @@ config ASN1
> inform it as to what tags are to be expected in a stream and what
> functions to call on what tags.
>  
> +config WEAK_PROVIDE_HIDDEN
> + bool
> + help
> +   Generate linker script PROVIDE_HIDDEN entries for all weak symbols. It
> +   allows to prevent non-pie code being replaced by the linker if the

non-PIE

> +   emit-relocs option is used instead of pie (useful for x86_64 pie).

PIEPIE).

> +


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH net-next v10 2/4] net: Introduce generic failover module

[Randy Dunlap]

Hi,

On 05/07/2018 03:10 PM, Sridhar Samudrala wrote:
> 
> Signed-off-by: Sridhar Samudrala 
> ---
>  MAINTAINERS|7 +
>  include/linux/netdevice.h  |   16 +
>  include/net/net_failover.h |   52 +++
>  net/Kconfig|   10 +
>  net/core/Makefile  |1 +
>  net/core/net_failover.c| 1044 
> 
>  6 files changed, 1130 insertions(+)
>  create mode 100644 include/net/net_failover.h
>  create mode 100644 net/core/net_failover.c


> diff --git a/net/Kconfig b/net/Kconfig
> index b62089fb1332..0540856676de 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -429,6 +429,16 @@ config MAY_USE_DEVLINK
>  config PAGE_POOL
> bool
>  
> +config NET_FAILOVER
> + tristate "Failover interface"
> + default m

Need some justification for default m (as opposed to n).

> + help
> +   This provides a generic interface for paravirtual drivers to listen
> +   for netdev register/unregister/link change events from pci ethernet

 PCI

> +   devices with the same MAC and takeover their datapath. This also
> +   enables live migration of a VM with direct attached VF by failing
> +   over to the paravirtual datapath when the VF is unplugged.
> +
>  endif   # if NET
>  
>  # Used by archs to tell that they support BPF JIT compiler plus which 
> flavour.

> diff --git a/net/core/net_failover.c b/net/core/net_failover.c
> new file mode 100644
> index ..8d60e74e3034
> --- /dev/null
> +++ b/net/core/net_failover.c
> @@ -0,0 +1,1044 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2018, Intel Corporation. */
> +
> +/* A common module to handle registrations and notifications for paravirtual
> + * drivers to enable accelerated datapath and support VF live migration.
> + *
> + * The notifier and event handling code is based on netvsc driver and 
> failover
> + * netdev management routines are based on bond/team driver.
> + *
> + */


> +/**
> + * net_failover_create - Create and register a failover instance
> + *
> + * @dev: standby netdev

* @standby_dev: standby netdev

> + *
> + * Creates a failover netdev and registers a failover instance for a standby
> + * netdev. Used by paravirtual drivers that use 3-netdev model.
> + * The failover netdev acts as a master device and controls 2 slave devices -
> + * the original standby netdev and a VF netdev with the same MAC gets
> + * registered as primary netdev.
> + *
> + * Return: pointer to failover instance
> + */
> +struct net_failover *net_failover_create(struct net_device *standby_dev)
> +{
> + struct device *dev = standby_dev->dev.parent;
> + struct net_device *failover_dev;
> + struct net_failover *failover;
> + int err;
> +
> + /* Alloc at least 2 queues, for now we are going with 16 assuming
> +  * that VF devices being enslaved won't have too many queues.
> +  */
> + failover_dev = alloc_etherdev_mq(sizeof(struct net_failover_info), 16);
> + if (!failover_dev) {
> + dev_err(dev, "Unable to allocate failover_netdev!\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + dev_net_set(failover_dev, dev_net(standby_dev));
> + SET_NETDEV_DEV(failover_dev, dev);
> +
> + failover_dev->netdev_ops = _dev_ops;
> + failover_dev->ethtool_ops = _ethtool_ops;
> +
> + /* Initialize the device options */
> + failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
> + failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
> +IFF_TX_SKB_SHARING);
> +
> + /* don't acquire failover netdev's netif_tx_lock when transmitting */
> + failover_dev->features |= NETIF_F_LLTX;
> +
> + /* Don't allow failover devices to change network namespaces. */
> + failover_dev->features |= NETIF_F_NETNS_LOCAL;
> +
> + failover_dev->hw_features = FAILOVER_VLAN_FEATURES |
> + NETIF_F_HW_VLAN_CTAG_TX |
> + NETIF_F_HW_VLAN_CTAG_RX |
> + NETIF_F_HW_VLAN_CTAG_FILTER;
> +
> + failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
> + failover_dev->features |= failover_dev->hw_features;
> +
> + memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
> +failover_dev->addr_len);
> +
> + failover_dev->min_mtu = standby_dev->min_mtu;
> + failover_dev->max_mtu = standby_dev->max_mtu;
> +
> + err = register_netdev(failover_dev);
> + if (err) {
> + dev_err(dev, "Unable to register failover_dev!\n");
> + goto err_register_netdev;
> + }
> +
> + netif_carrier_off(failover_dev);
> +
> + failover = net_failover_register(failover_dev, NULL);
> + if (IS_ERR(failover))
> + goto err_failover_register;
> +
> + return failover;
> +
> +err_failover_register:
> + 

Re: [PATCH] fault-injection: reorder config entries

[Randy Dunlap]

On 04/25/2018 01:02 PM, Mikulas Patocka wrote:
> This patch reorders Kconfig entries, so that menuconfig displays proper 
> indentation.
> 
> Signed-off-by: Mikulas Patocka <mpato...@redhat.com>

Acked-by: Randy Dunlap <rdun...@infradead.org>
Tested-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

> ---
>  lib/Kconfig.debug |   36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> Index: linux-2.6/lib/Kconfig.debug
> ===
> --- linux-2.6.orig/lib/Kconfig.debug  2018-04-16 21:08:36.0 +0200
> +++ linux-2.6/lib/Kconfig.debug   2018-04-25 15:56:16.0 +0200
> @@ -1503,6 +1503,10 @@ config NETDEV_NOTIFIER_ERROR_INJECT
>  
> If unsure, say N.
>  
> +config FUNCTION_ERROR_INJECTION
> + def_bool y
> + depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
> +
>  config FAULT_INJECTION
>   bool "Fault-injection framework"
>   depends on DEBUG_KERNEL
> @@ -1510,10 +1514,6 @@ config FAULT_INJECTION
> Provide fault-injection framework.
> For more details, see Documentation/fault-injection/.
>  
> -config FUNCTION_ERROR_INJECTION
> - def_bool y
> - depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
> -
>  config FAILSLAB
>   bool "Fault-injection capability for kmalloc"
>   depends on FAULT_INJECTION
> @@ -1544,16 +1544,6 @@ config FAIL_IO_TIMEOUT
> Only works with drivers that use the generic timeout handling,
> for others it wont do anything.
>  
> -config FAIL_MMC_REQUEST
> - bool "Fault-injection capability for MMC IO"
> - depends on FAULT_INJECTION_DEBUG_FS && MMC
> - help
> -   Provide fault-injection capability for MMC IO.
> -   This will make the mmc core return data errors. This is
> -   useful to test the error handling in the mmc block device
> -   and to test how the mmc host driver handles retries from
> -   the block device.
> -
>  config FAIL_FUTEX
>   bool "Fault-injection capability for futexes"
>   select DEBUG_FS
> @@ -1561,6 +1551,12 @@ config FAIL_FUTEX
>   help
> Provide fault-injection capability for futexes.
>  
> +config FAULT_INJECTION_DEBUG_FS
> + bool "Debugfs entries for fault-injection capabilities"
> + depends on FAULT_INJECTION && SYSFS && DEBUG_FS
> + help
> +   Enable configuration of fault-injection capabilities via debugfs.
> +
>  config FAIL_FUNCTION
>   bool "Fault-injection capability for functions"
>   depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
> @@ -1571,11 +1567,15 @@ config FAIL_FUNCTION
> an error value and have to handle it. This is useful to test the
> error handling in various subsystems.
>  
> -config FAULT_INJECTION_DEBUG_FS
> - bool "Debugfs entries for fault-injection capabilities"
> - depends on FAULT_INJECTION && SYSFS && DEBUG_FS
> +config FAIL_MMC_REQUEST
> + bool "Fault-injection capability for MMC IO"
> + depends on FAULT_INJECTION_DEBUG_FS && MMC
>   help
> -   Enable configuration of fault-injection capabilities via debugfs.
> +   Provide fault-injection capability for MMC IO.
> +   This will make the mmc core return data errors. This is
> +   useful to test the error handling in the mmc block device
> +   and to test how the mmc host driver handles retries from
> +   the block device.
>  
>  config FAULT_INJECTION_STACKTRACE_FILTER
>   bool "stacktrace filter for fault-injection capabilities"
> 


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5] fault-injection: introduce kvmalloc fallback options

[Randy Dunlap]

On 04/25/2018 01:57 PM, Mikulas Patocka wrote:
> 
> 
> On Wed, 25 Apr 2018, Randy Dunlap wrote:
> 
>> On 04/25/2018 01:02 PM, Mikulas Patocka wrote:
>>>
>>>
>>> From: Mikulas Patocka <mpato...@redhat.com>
>>> Subject: [PATCH v4] fault-injection: introduce kvmalloc fallback options
>>>
>>> This patch introduces a fault-injection option "kvmalloc_fallback". This
>>> option makes kvmalloc randomly fall back to vmalloc.
>>>
>>> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
>>
>>   Unfortunately,
> 
> OK - here I fixed the typos:
> 
> 
> From: Mikulas Patocka <mpato...@redhat.com>
> Subject: [PATCH] fault-injection: introduce kvmalloc fallback options
> 
> This patch introduces a fault-injection option "kvmalloc_fallback". This
> option makes kvmalloc randomly fall back to vmalloc.
> 
> Unfortunately, some kernel code has bugs - it uses kvmalloc and then
> uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific
> code. This options helps to test for these bugs.
> 
> The patch introduces a config option FAIL_KVMALLOC_FALLBACK_PROBABILITY.
> It can be enabled in distribution debug kernels, so that kvmalloc abuse
> can be tested by the users. The default can be overridden with
> "kvmalloc_fallback" parameter or in /sys/kernel/debug/kvmalloc_fallback/.
> 
> Signed-off-by: Mikulas Patocka <mpato...@redhat.com>
> 
> ---
>  Documentation/fault-injection/fault-injection.txt |7 +
>  include/linux/fault-inject.h  |9 +++---
>  kernel/futex.c|2 -
>  lib/Kconfig.debug |   15 +++
>  mm/failslab.c         |2 -
>  mm/page_alloc.c   |2 -
>  mm/util.c |   30 
> ++
>  7 files changed, 60 insertions(+), 7 deletions(-)

Acked-by: Randy Dunlap <rdun...@infradead.org> # Documentation and Kconfig only

thanks.
-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4] fault-injection: introduce kvmalloc fallback options

[Randy Dunlap]

On 04/25/2018 01:02 PM, Mikulas Patocka wrote:
> 
> 
> From: Mikulas Patocka 
> Subject: [PATCH v4] fault-injection: introduce kvmalloc fallback options
> 
> This patch introduces a fault-injection option "kvmalloc_fallback". This
> option makes kvmalloc randomly fall back to vmalloc.
> 
> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then

  Unfortunately,

> uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific
> code. This options helps to test for these bugs.
> 
> The patch introduces a config option FAIL_KVMALLOC_FALLBACK_PROBABILITY.
> It can be enabled in distribution debug kernels, so that kvmalloc abuse
> can be tested by the users. The default can be overriden with

 overridden

> "kvmalloc_fallback" parameter or in /sys/kernel/debug/kvmalloc_fallback/.
> 
> Signed-off-by: Mikulas Patocka 
> 
> ---
>  Documentation/fault-injection/fault-injection.txt |7 +
>  include/linux/fault-inject.h  |9 +++---
>  kernel/futex.c|2 -
>  lib/Kconfig.debug |   15 +++
>  mm/failslab.c |2 -
>  mm/page_alloc.c   |2 -
>  mm/util.c |   30 
> ++
>  7 files changed, 60 insertions(+), 7 deletions(-)
> 
> Index: linux-2.6/Documentation/fault-injection/fault-injection.txt
> ===
> --- linux-2.6.orig/Documentation/fault-injection/fault-injection.txt  
> 2018-04-16 21:08:34.0 +0200
> +++ linux-2.6/Documentation/fault-injection/fault-injection.txt   
> 2018-04-25 21:36:36.0 +0200
> @@ -15,6 +15,12 @@ o fail_page_alloc
>  
>injects page allocation failures. (alloc_pages(), get_free_pages(), ...)
>  
> +o kvmalloc_faillback

 kvmalloc_fallback

> +
> +  makes the function kvmalloc randonly fall back to vmalloc. This could be 
> used

 randomly

> +  to detects bugs such as using DMA-API on the result of kvmalloc or freeing
> +  the result of kvmalloc with free.
> +
>  o fail_futex
>  
>injects futex deadlock and uaddr fault errors.
> @@ -167,6 +173,7 @@ use the boot option:
>  
>   failslab=
>   fail_page_alloc=
> + kvmalloc_faillback=

kvmalloc_fallback=

>   fail_make_request=
>   fail_futex=
>   mmc_core.fail_request=,,,

> Index: linux-2.6/lib/Kconfig.debug
> ===
> --- linux-2.6.orig/lib/Kconfig.debug  2018-04-25 15:56:16.0 +0200
> +++ linux-2.6/lib/Kconfig.debug   2018-04-25 21:39:45.0 +0200
> @@ -1527,6 +1527,21 @@ config FAIL_PAGE_ALLOC
>   help
> Provide fault-injection capability for alloc_pages().
>  
> +config FAIL_KVMALLOC_FALLBACK_PROBABILITY
> + int "Default kvmalloc fallback probability"
> + depends on FAULT_INJECTION
> + range 0 100
> + default "0"
> + help
> +   This option will make kvmalloc randomly fall back to vmalloc.
> +   Normally, kvmalloc falls back to vmalloc only rarely, if memory
> +   is fragmented.
> +
> +   This option helps to detect hard-to-reproduce driver bugs, for
> +   example using DMA API on the result of kvmalloc.
> +
> +   The default may be overriden with the kvmalloc_faillback parameter.

 overridden kvmalloc_fallback

> +
>  config FAIL_MAKE_REQUEST
>   bool "Fault-injection capability for disk IO"
>   depends on FAULT_INJECTION && BLOCK

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/11/2018 11:27 PM, Ingo Molnar wrote:
> 
> * Randy Dunlap <rdun...@infradead.org> wrote:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> Nice find:
> 
> Reviewed-by: Ingo Molnar <mi...@kernel.org>
> 
> I agree that it needs to go through 0-day to find any hidden dependencies we 
> might 
> have grown due to this.

Andrew,

This patch has mostly survived both 0day and ozlabs multi-arch testing with
2 build errors being reported by both of them.  I have posted patches for
those separately. (and are attached here)

other-patch-1:
lkml.kernel.org/r/5664ced1-a0cd-7e4e-71b6-9c3a97d68...@infradead.org
"lib/test_firmware: add header file to prevent build errors"

other-patch-2:
lkml.kernel.org/r/b3b7eebb-0e9f-f175-94a8-379c5ddca...@infradead.org
"integrity/security: fix digsig.c build error"

Will you see that these are merged or do you want me to repost them?

thanks,
-- 
~Randy
From: Randy Dunlap <rdun...@infradead.org>

security/integrity/digsig.c has build errors on some $ARCH due to a
missing header file, so add it.

  security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]

Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Mimi Zohar <zo...@linux.vnet.ibm.com>
Cc: linux-integr...@vger.kernel.org
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
 security/integrity/digsig.c |    1 +
 1 file changed, 1 insertion(+)

--- lnx-416-rc1.orig/security/integrity/digsig.c
+++ lnx-416-rc1/security/integrity/digsig.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 



From: Randy Dunlap <rdun...@infradead.org>

lib/test_firmware.c has build errors on some $ARCH due to a
missing header file, so add it.

  lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
  lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]

Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Wei Yongjun <weiyongj...@huawei.com>
Cc: Luis R. Rodriguez <mcg...@kernel.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
 lib/test_firmware.c |1 +
 1 file changed, 1 insertion(+)

--- lnx-416-rc1.orig/lib/test_firmware.c
+++ lnx-416-rc1/lib/test_firmware.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TEST_FIRMWARE_NAME	"test-firmware.bin"
 #define TEST_FIRMWARE_NUM_REQS	4



___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/13/2018 02:09 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> On 02/12/2018 04:28 AM, Michael Ellerman wrote:
>>> Randy Dunlap <rdun...@infradead.org> writes:
>>>
>>>> From: Randy Dunlap <rdun...@infradead.org>
>>>>
>>>> Currently  #includes  for no obvious
>>>> reason. It looks like it's only a convenience, so remove kmemleak.h
>>>> from slab.h and add  to any users of kmemleak_*
>>>> that don't already #include it.
>>>> Also remove  from source files that do not use it.
>>>>
>>>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>>>> would be good to run it through the 0day bot for other $ARCHes.
>>>> I have neither the horsepower nor the storage space for the other
>>>> $ARCHes.
>>>>
>>>> [slab.h is the second most used header file after module.h; kernel.h
>>>> is right there with slab.h. There could be some minor error in the
>>>> counting due to some #includes having comments after them and I
>>>> didn't combine all of those.]
>>>>
>>>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>>>> header files).
>>>>
>>>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
>>>
>>> I threw it at a random selection of configs and so far the only failures
>>> I'm seeing are:
>>>
>>>   lib/test_firmware.c:134:2: error: implicit declaration of function 
>>> 'vfree' [-Werror=implicit-function-declaration] 
>>> 
>>>  
>>>   lib/test_firmware.c:620:25: error: implicit declaration of function 
>>> 'vzalloc' [-Werror=implicit-function-declaration]
>>>   lib/test_firmware.c:620:2: error: implicit declaration of function 
>>> 'vzalloc' [-Werror=implicit-function-declaration]
>>>   security/integrity/digsig.c:146:2: error: implicit declaration of 
>>> function 'vfree' [-Werror=implicit-function-declaration]
>>
>> Both of those source files need to #include .
> 
> Yep, I added those and rebuilt. I don't see any more failures that look
> related to your patch.

Great, thanks.

I also sent patches for both of those.

>   http://kisskb.ellerman.id.au/kisskb/head/13399/
> 
> 
> I haven't gone through the defconfigs I have enabled for a while, so
> it's possible I have some missing but it's still a reasonable cross
> section.


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 

Both of those source files need to #include .

> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/
> 
> cheers

:)

-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Currently  #includes  for no obvious
reason. It looks like it's only a convenience, so remove kmemleak.h
from slab.h and add  to any users of kmemleak_*
that don't already #include it.
Also remove  from source files that do not use it.

This is tested on i386 allmodconfig and x86_64 allmodconfig. It
would be good to run it through the 0day bot for other $ARCHes.
I have neither the horsepower nor the storage space for the other
$ARCHes.

[slab.h is the second most used header file after module.h; kernel.h
is right there with slab.h. There could be some minor error in the
counting due to some #includes having comments after them and I
didn't combine all of those.]

This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
header files).

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---

Fengguang, can you have this patch run thru 0day builds, please?

 arch/powerpc/sysdev/dart_iommu.c  |1 +
 arch/powerpc/sysdev/msi_bitmap.c  |1 +
 arch/s390/kernel/nmi.c|2 +-
 arch/s390/kernel/smp.c|1 -
 arch/sparc/kernel/irq_64.c|1 -
 arch/x86/kernel/pci-dma.c |1 -
 drivers/iommu/exynos-iommu.c  |1 +
 drivers/iommu/mtk_iommu_v1.c  |1 -
 drivers/net/ethernet/ti/cpsw.c|1 +
 drivers/net/wireless/realtek/rtlwifi/pci.c|1 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c |1 -
 drivers/staging/rtl8188eu/hal/fw.c|2 +-
 drivers/staging/rtlwifi/pci.c |1 -
 drivers/virtio/virtio_ring.c  |1 -
 include/linux/slab.h  |1 -
 kernel/ucount.c   |1 +
 mm/cma.c  |1 +
 mm/memblock.c |1 +
 net/core/sysctl_net_core.c|1 -
 net/ipv4/route.c  |1 -
 security/apparmor/lsm.c   |1 -
 21 files changed, 9 insertions(+), 14 deletions(-)

--- lnx-416-rc1.orig/include/linux/slab.h
+++ lnx-416-rc1/include/linux/slab.h
@@ -125,7 +125,6 @@
 #define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
(unsigned long)ZERO_SIZE_PTR)
 
-#include 
 #include 
 
 struct mem_cgroup;
--- lnx-416-rc1.orig/kernel/ucount.c
+++ lnx-416-rc1/kernel/ucount.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define UCOUNTS_HASHTABLE_BITS 10
--- lnx-416-rc1.orig/mm/memblock.c
+++ lnx-416-rc1/mm/memblock.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
--- lnx-416-rc1.orig/mm/cma.c
+++ lnx-416-rc1/mm/cma.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "cma.h"
--- lnx-416-rc1.orig/drivers/staging/rtl8188eu/hal/fw.c
+++ lnx-416-rc1/drivers/staging/rtl8188eu/hal/fw.c
@@ -30,7 +30,7 @@
 #include "rtl8188e_hal.h"
 
 #include 
-#include 
+#include 
 
 static void _rtl88e_enable_fw_download(struct adapter *adapt, bool enable)
 {
--- lnx-416-rc1.orig/drivers/iommu/exynos-iommu.c
+++ lnx-416-rc1/drivers/iommu/exynos-iommu.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/s390/kernel/nmi.c
+++ lnx-416-rc1/arch/s390/kernel/nmi.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/powerpc/sysdev/dart_iommu.c
+++ lnx-416-rc1/arch/powerpc/sysdev/dart_iommu.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/powerpc/sysdev/msi_bitmap.c
+++ lnx-416-rc1/arch/powerpc/sysdev/msi_bitmap.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/drivers/net/ethernet/ti/cpsw.c
+++ lnx-416-rc1/drivers/net/ethernet/ti/cpsw.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
--- lnx-416-rc1.orig/drivers/virtio/virtio_ring.c
+++ lnx-416-rc1/drivers/virtio/virtio_ring.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
--- lnx-416-rc1.orig/security/apparmor/lsm.c
+++ lnx-416-rc1/security/apparmor/lsm.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "include/apparmor.h"
--- lnx-416-rc1.orig/drivers/iommu/mtk_iommu_v1.c
+++ lnx-416-rc1/drivers/iommu/mtk_iommu_v1.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/drivers/

Re: [PATCH] [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

[Randy Dunlap]

On 01/03/18 01:49, Vincent Legoll wrote:
> No need to get into the submenu to disable all VIRTIO-related
> config entries.
> 
> This makes it easier to disable all VIRTIO config options
> without entering the submenu. It will also enable one
> to see that en/dis-abled state from the outside menu.
> 
> This is only intended to change menuconfig UI, not change
> the config dependencies.
> 
> v2: add "default y" to avoid breaking existing configs
> 
> Signed-off-by: Vincent Legoll <vincent.leg...@gmail.com>

For a single patch (not 2 or more in a series), please just use one
email with the patch description etc. in it.  No need for a cover letter.

> ---
>  drivers/virtio/Kconfig | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index cff773f15b7e..290a1875e1d3 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -5,7 +5,11 @@ config VIRTIO
> bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG
> or CONFIG_S390_GUEST.
>  
> -menu "Virtio drivers"
> +menuconfig VIRTIO_MENU
> +   bool "Virtio drivers"
> +   default y

The 2 lines above should be indented only with 1 tab.  They should not line up
with the help text above (help text is indented more than other Kconfig lines).

After that little style thing is fixed, you can add:

Reviewed-by: Randy Dunlap <rdun...@infradead.org>
Tested-by: Randy Dunlap <rdun...@infradead.org> # works for me

and even though this will disable the drivers that are listed immediately
inside this if/endif block, there are several other drivers that select VIRTIO,
so it can be slightly tricky to figure out what is causing CONFIG_VIRTIO
to be enabled after having disabled CONFIG_VIRTIO_MENU.

Thanks.

> +
> +if VIRTIO_MENU
>  
>  config VIRTIO_PCI
>   tristate "PCI driver for virtio devices"
> @@ -79,4 +83,4 @@ config VIRTIO_MMIO_CMDLINE_DEVICES
>  
>If unsure, say 'N'.
>  
> -endmenu
> +endif # VIRTIO_MENU
> 


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Jul 21 (gpu/virtio)

[Randy Dunlap]

On 07/20/16 23:56, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160720:
> 

on x86_64, when CONFIG_FB is not enabled:

ERROR: "remove_conflicting_framebuffers" [drivers/gpu/drm/virtio/virtio-gpu.ko] 
undefined!


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Jun 26 (xen/x86)

[Randy Dunlap]

On 06/26/13 01:06, Stephen Rothwell wrote:
 Hi all,
 
 Changes since 20130625:
 

CONFIG_SMP is not set
CONFIG_X86_UP_APIC is not set

on i386:

drivers/built-in.o: In function `xen_callback_vector':
(.text+0x1dc3cb): undefined reference to `first_system_vector'
drivers/built-in.o: In function `xen_callback_vector':
(.text+0x1dc3f5): undefined reference to `first_system_vector'


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec

[Randy Dunlap]

On 05/16/13 16:42, Rusty Russell wrote:
 Joe Perches j...@perches.com writes:
 On Thu, 2013-05-16 at 13:04 +0930, Rusty Russell wrote:
 Asias He as...@redhat.com writes:
 On Wed, May 15, 2013 at 02:47:53PM +0930, Rusty Russell wrote:
 []
 Other users are using memcpy_fromiovec and friends outside net. It seems
 a good idea to put it in a util library. e.g.  crypto/algif_skcipher.c
 which also depends on NET for it.

 []
 Subject: Hoist memcpy_fromiovec into lib/

 You'll need the friends memcpy_toiovec too.

 $ git grep -E \bmemcpy\w+iovec\w*
 crypto/algif_hash.c:err = memcpy_toiovec(msg-msg_iov, ctx-result, len);
 crypto/algif_skcipher.c:err = 
 memcpy_fromiovec(page_address(sg_page(sg)) +
 crypto/algif_skcipher.c:err = 
 memcpy_fromiovec(page_address(sg_page(sg + i)),
 drivers/dma/iovlock.c:#include net/tcp.h /* for memcpy_toiovec */
 drivers/dma/iovlock.c:  return memcpy_toiovec(iov, kdata, len);
 drivers/dma/iovlock.c:  err = memcpy_toiovec(iov, vaddr + offset, 
 len);
 drivers/isdn/mISDN/socket.c:if (memcpy_fromiovec(skb_put(skb, len), 
 msg-msg_iov, len)) {
 drivers/misc/vmw_vmci/vmci_queue_pair.c:err = 
 memcpy_fromiovec((u8 *)va + page_o
 drivers/misc/vmw_vmci/vmci_queue_pair.c:err = 
 memcpy_toiovec(iov, (u8 *)va + pag
 
 Fascinating.  These all indirectly depend on NET, so there's no problem
 at the moment.  But it is a bit weird...
 
 crypto/algif_hash.c: depends on CRYPTO_USER_API_HASH - NET
 crypto/algif_skcipher.c: depends on CRYPTO_USER_API_SKCIPHER - NET
 drivers/dma/iovlock.c: depends on NET_DMA - NET
 drivers/isdn/mISDN/socket.c: depends on MISDN - ISDN - NET
 drivers/misc/vmw_vmci/vmci_queue_pair.c: depends on VMCI - NET
 
 Patch welcome.
 
 Meanwhile, to avoid more bikeshedding I've put the patch I posted with
 all acks in my fixes branch.  One cycle through linux-next, then
 straight to Linus.
 

I agree with whoever suggested that more be moved into /lib.
E.g., drivers/misc/vmw_vmci/Kconfig uses depends on NET because the
code there uses both memcpy_toiovec() and memcpy_fromiovec().
See commit ID 6d4f0139d642c45411a47879325891ce2a7c164a.


 Subject: Hoist memcpy_fromiovec into lib/
 
 ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined!
 
 That function is only present with CONFIG_NET.  Turns out that
 crypto/algif_skcipher.c also uses that outside net, but it actually
 needs sockets anyway.
 
 socket.h already include uio.h, so no callers need updating.
 
 Reported-by: Randy Dunlap rdun...@infradead.org
 Acked-by: David S. Miller da...@davemloft.net
 Acked-by: Michael S. Tsirkin m...@redhat.com
 Signed-off-by: Rusty Russell ru...@rustcorp.com.au
 
 diff --git a/include/linux/socket.h b/include/linux/socket.h
 index 428c37a..7266775 100644
 --- a/include/linux/socket.h
 +++ b/include/linux/socket.h
 @@ -305,7 +305,6 @@ struct ucred {
  
  extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct 
 ucred *ucred);
  
 -extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int 
 len);
  extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
  int offset, int len);
  extern int csum_partial_copy_fromiovecend(unsigned char *kdata, 
 diff --git a/include/linux/uio.h b/include/linux/uio.h
 index 629aaf5..21628d3 100644
 --- a/include/linux/uio.h
 +++ b/include/linux/uio.h
 @@ -35,4 +35,6 @@ static inline size_t iov_length(const struct iovec *iov, 
 unsigned long nr_segs)
  }
  
  unsigned long iov_shorten(struct iovec *iov, unsigned long nr_segs, size_t 
 to);
 +
 +int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len);
  #endif
 diff --git a/lib/Makefile b/lib/Makefile
 index e9c52e1..2377211 100644
 --- a/lib/Makefile
 +++ b/lib/Makefile
 @@ -9,7 +9,7 @@ endif
  
  lib-y := ctype.o string.o vsprintf.o cmdline.o \
rbtree.o radix-tree.o dump_stack.o timerqueue.o\
 -  idr.o int_sqrt.o extable.o \
 +  idr.o int_sqrt.o extable.o iovec.o \
sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \
proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \
is_single_threaded.o plist.o decompress.o kobject_uevent.o \
 diff --git a/lib/iovec.c b/lib/iovec.c
 new file mode 100644
 index 000..632c5ea
 --- /dev/null
 +++ b/lib/iovec.c
 @@ -0,0 +1,29 @@
 +#include linux/uaccess.h
 +#include linux/export.h
 +#include linux/uio.h
 +
 +/*
 + *   Copy iovec to kernel. Returns -EFAULT on error.
 + *
 + *   Note: this modifies the original iovec.
 + */
 +
 +int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len)
 +{
 + while (len  0) {
 + if (iov-iov_len) {
 + int copy = min_t(unsigned int, len, iov-iov_len);
 + if (copy_from_user(kdata, iov-iov_base, copy))
 + return -EFAULT;
 + len -= copy

Re: linux-next: Tree for May 14 (vhost_scsi)

[Randy Dunlap]

On 05/13/13 21:17, Stephen Rothwell wrote:
 Hi all,
 
 Changes since 20130513:
 
 crickets :-)


on x86_64:

ERROR: memcpy_fromiovec [drivers/vhost/vhost_scsi.ko] undefined!


It needs to depend on NET since net/core/ provides that function.


-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH] xen: fix fbdev frontend kconfig warning

[Randy Dunlap]

From: Randy Dunlap rdun...@infradead.org

Fix kconfig dependency warning for XEN_FBDEV_FRONTEND:

warning: (XEN_FBDEV_FRONTEND) selects INPUT_XEN_KBDDEV_FRONTEND which has unmet 
direct dependencies (!UML  INPUT  INPUT_MISC  XEN)

Signed-off-by: Randy Dunlap rdun...@infradead.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Jeremy Fitzhardinge jer...@goop.org
Cc: xen-de...@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
---
 drivers/video/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-39-rc4.orig/drivers/video/Kconfig
+++ lnx-39-rc4/drivers/video/Kconfig
@@ -2277,7 +2277,7 @@ config XEN_FBDEV_FRONTEND
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
-   select INPUT_XEN_KBDDEV_FRONTEND
+   select INPUT_XEN_KBDDEV_FRONTEND if INPUT
select XEN_XENBUS_FRONTEND
default y
help
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Feb 13 (virtio_console)

[Randy Dunlap]

On 02/13/13 19:00, Rusty Russell wrote:
 Randy Dunlap rdun...@infradead.org writes:
 
 On 02/13/13 00:35, Stephen Rothwell wrote:
 Hi all,

 Changes since 20130212:

 on i386:

 drivers/built-in.o: In function `in_intr':
 virtio_console.c:(.text+0x2dd31): undefined reference to `hvc_poll'
 virtio_console.c:(.text+0x2dd41): undefined reference to `hvc_kick'
 drivers/built-in.o: In function `resize_console':
 virtio_console.c:(.text+0x2e26f): undefined reference to `__hvc_resize'
 drivers/built-in.o: In function `unplug_port':
 virtio_console.c:(.text+0x2e572): undefined reference to `hvc_remove'
 drivers/built-in.o: In function `init_port_console':
 (.text+0x2fe59): undefined reference to `hvc_alloc'
 drivers/built-in.o: In function `virtio_cons_early_init':
 (.init.text+0x16d1): undefined reference to `hvc_instantiate'


 Full randconfig file is attached.
 
 This looks like an impossible config.  CONFIG_VIRTIO_CONSOLE=y, but
 CONFIG_HVC_DRIVER isn't set.
 
 From drivers/char/Kconfig:
 
 config VIRTIO_CONSOLE
   tristate Virtio console
   depends on VIRTIO
   select HVC_DRIVER
 
 ???

OK.  It's probably yet another stinking problem with kvmtool and randconfig.
Running *config reports:

warning: (KVMTOOL_TEST_ENABLE  LGUEST_GUEST) selects VIRTIO_CONSOLE which has 
unmet direct dependencies (VIRTIO  TTY)


I'll look a bit more...

thanks,
-- 
~Randy
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Feb 13 (virtio_console)

[Randy Dunlap]

On 02/14/13 10:45, Randy Dunlap wrote:
 On 02/13/13 19:00, Rusty Russell wrote:
 Randy Dunlap rdun...@infradead.org writes:

 On 02/13/13 00:35, Stephen Rothwell wrote:
 Hi all,

 Changes since 20130212:

 on i386:

 drivers/built-in.o: In function `in_intr':
 virtio_console.c:(.text+0x2dd31): undefined reference to `hvc_poll'
 virtio_console.c:(.text+0x2dd41): undefined reference to `hvc_kick'
 drivers/built-in.o: In function `resize_console':
 virtio_console.c:(.text+0x2e26f): undefined reference to `__hvc_resize'
 drivers/built-in.o: In function `unplug_port':
 virtio_console.c:(.text+0x2e572): undefined reference to `hvc_remove'
 drivers/built-in.o: In function `init_port_console':
 (.text+0x2fe59): undefined reference to `hvc_alloc'
 drivers/built-in.o: In function `virtio_cons_early_init':
 (.init.text+0x16d1): undefined reference to `hvc_instantiate'


 Full randconfig file is attached.

 This looks like an impossible config.  CONFIG_VIRTIO_CONSOLE=y, but
 CONFIG_HVC_DRIVER isn't set.

 From drivers/char/Kconfig:

 config VIRTIO_CONSOLE
  tristate Virtio console
  depends on VIRTIO
  select HVC_DRIVER

 ???
 
 OK.  It's probably yet another stinking problem with kvmtool and randconfig.
 Running *config reports:
 
 warning: (KVMTOOL_TEST_ENABLE  LGUEST_GUEST) selects VIRTIO_CONSOLE which 
 has unmet direct dependencies (VIRTIO  TTY)
 
 
 I'll look a bit more...

Nope, that's not it.  Stephen's comments were much closer.

The patch below fixes the kconfig warning and the build errors.
---



From: Randy Dunlap rdun...@infradead.org

Fix kconfig warning for LGUEST_GUEST config by selecting TTY:

warning: (KVMTOOL_TEST_ENABLE  LGUEST_GUEST) selects VIRTIO_CONSOLE which has 
unmet direct dependencies (VIRTIO  TTY)

Signed-off-by: Randy Dunlap rdun...@infradead.org
---
 arch/x86/lguest/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- linux-next-20130213.orig/arch/x86/lguest/Kconfig
+++ linux-next-20130213/arch/x86/lguest/Kconfig
@@ -2,6 +2,7 @@ config LGUEST_GUEST
bool Lguest guest support
select PARAVIRT
depends on X86_32
+   select TTY
select VIRTUALIZATION
select VIRTIO
select VIRTIO_CONSOLE
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: linux-next: Tree for Jan 10 (vmci)

[Randy Dunlap]

On 01/10/13 11:17, Randy Dunlap wrote:
 On 01/09/13 19:32, Stephen Rothwell wrote:
 Hi all,

 Changes since 20130109:

 
 
 on i386, when CONFIG_PCI is not enabled:
 
   CC [M]  drivers/misc/vmw_vmci/vmci_guest.o
 drivers/misc/vmw_vmci/vmci_guest.c:58:20: error: array type has incomplete 
 element type
 drivers/misc/vmw_vmci/vmci_guest.c: In function 'vmci_enable_msix':
 drivers/misc/vmw_vmci/vmci_guest.c:384:2: error: implicit declaration of 
 function 'pci_enable_msix' [-Werror=implicit-function-declaration]
 drivers/misc/vmw_vmci/vmci_guest.c: In function 'vmci_guest_probe_device':
 drivers/misc/vmw_vmci/vmci_guest.c:466:2: error: implicit declaration of 
 function 'pcim_enable_device' [-Werror=implicit-function-declaration]
 drivers/misc/vmw_vmci/vmci_guest.c:592:2: error: implicit declaration of 
 function 'pci_enable_msi' [-Werror=implicit-function-declaration]
 drivers/misc/vmw_vmci/vmci_guest.c:654:3: error: implicit declaration of 
 function 'pci_disable_msix' [-Werror=implicit-function-declaration]
 drivers/misc/vmw_vmci/vmci_guest.c:656:3: error: implicit declaration of 
 function 'pci_disable_msi' [-Werror=implicit-function-declaration]
 cc1: some warnings being treated as errors
 make[4]: *** [drivers/misc/vmw_vmci/vmci_guest.o] Error 1
 
 
 Should all of vmci depend on PCI ??
 
 


Also on i386, when CONFIG_BLOCK is not enabled:

  CC [M]  drivers/misc/vmw_vmci/vmci_queue_pair.o
In file included from drivers/misc/vmw_vmci/vmci_queue_pair.c:16:0:
include/linux/device-mapper.h:48:56: warning: 'struct bio' declared inside 
parameter list [enabled by default]
include/linux/device-mapper.h:48:56: warning: its scope is only this definition 
or declaration, which is probably not what you want [enabled by default]
include/linux/device-mapper.h:50:13: warning: 'struct request' declared inside 
parameter list [enabled by default]
include/linux/device-mapper.h:61:15: warning: 'struct bio' declared inside 
parameter list [enabled by default]
include/linux/device-mapper.h:64:15: warning: 'struct request' declared inside 
parameter list [enabled by default]
include/linux/device-mapper.h:80:15: warning: 'struct bvec_merge_data' declared 
inside parameter list [enabled by default]
include/linux/device-mapper.h:92:12: warning: 'struct queue_limits' declared 
inside parameter list [enabled by default]
include/linux/device-mapper.h:265:13: error: field 'clone' has incomplete type
include/linux/device-mapper.h: In function 'dm_bio_get_target_request_nr':
include/linux/device-mapper.h:280:9: warning: initialization from incompatible 
pointer type [enabled by default]
include/linux/device-mapper.h: At top level:
include/linux/device-mapper.h:376:42: warning: 'struct request' declared inside 
parameter list [enabled by default]
include/linux/device-mapper.h:563:33: warning: 'struct request' declared inside 
parameter list [enabled by default]
include/linux/device-mapper.h:564:41: warning: 'struct request' declared inside 
parameter list [enabled by default]
include/linux/device-mapper.h:565:38: warning: 'struct request' declared inside 
parameter list [enabled by default]
drivers/misc/vmw_vmci/vmci_queue_pair.c: In function 'qp_alloc_ppn_set':
drivers/misc/vmw_vmci/vmci_queue_pair.c:476:6: error: implicit declaration of 
function 'kmalloc' [-Werror=implicit-function-declaration]
drivers/misc/vmw_vmci/vmci_queue_pair.c:475:15: warning: assignment makes 
pointer from integer without a cast [enabled by default]
drivers/misc/vmw_vmci/vmci_queue_pair.c:480:15: warning: assignment makes 
pointer from integer without a cast [enabled by default]
drivers/misc/vmw_vmci/vmci_queue_pair.c:483:3: error: implicit declaration of 
function 'kfree' [-Werror=implicit-function-declaration]
drivers/misc/vmw_vmci/vmci_queue_pair.c: In function 'qp_host_alloc_queue':
drivers/misc/vmw_vmci/vmci_queue_pair.c:619:2: error: implicit declaration of 
function 'kzalloc' [-Werror=implicit-function-declaration]
drivers/misc/vmw_vmci/vmci_queue_pair.c:619:8: warning: assignment makes 
pointer from integer without a cast [enabled by default]
drivers/misc/vmw_vmci/vmci_queue_pair.c: In function 'qp_release_pages':
drivers/misc/vmw_vmci/vmci_queue_pair.c:717:3: error: implicit declaration of 
function 'page_cache_release' [-Werror=implicit-function-declaration]
drivers/misc/vmw_vmci/vmci_queue_pair.c: In function 'qp_guest_endpoint_create':
drivers/misc/vmw_vmci/vmci_queue_pair.c:975:8: warning: assignment makes 
pointer from integer without a cast [enabled by default]
drivers/misc/vmw_vmci/vmci_queue_pair.c: In function 'qp_alloc_hypercall':
drivers/misc/vmw_vmci/vmci_queue_pair.c:1033:12: warning: assignment makes 
pointer from integer without a cast [enabled by default]
drivers/misc/vmw_vmci/vmci_queue_pair.c: In function 'qp_broker_create':
drivers/misc/vmw_vmci/vmci_queue_pair.c:1396:8: warning: assignment makes 
pointer from integer without a cast [enabled by default]
drivers/misc/vmw_vmci/vmci_queue_pair.c:1450:3: error: implicit declaration

Re: [Xen-devel] Re: linux-next: Tree for July 25 (xen)

[Randy Dunlap]

On Thu, 4 Aug 2011 15:55:39 -0400 Konrad Rzeszutek Wilk wrote:

 On Thu, Aug 04, 2011 at 09:35:34PM +0200, Ingo Molnar wrote:
  
  * Randy Dunlap rdun...@xenotime.net wrote:
  
   On Mon, 25 Jul 2011 16:25:42 +1000 Stephen Rothwell wrote:
   
Hi all,
   
   xen has lots of build errors and warnings (all on x86_64).
 
 Hm, I have a fix in my linux-next (and stable/bug.fixes) for this that I was 
 thinking
 to send in a couple of days ..
 
 
 commit 1e9ea2656b656edd3c8de98675bbc0340211b5bd
 Author: Jeremy Fitzhardinge jer...@goop.org
 Date:   Wed Aug 3 09:43:44 2011 -0700
 
  xen/tracing: it looks like we wanted CONFIG_FTRACE
 
 Apparently we wanted CONFIG_FTRACE rather the CONFIG_FUNCTION_TRACER.
 
 Reported-by: Sander Eikelenboom li...@eikelenboom.it
 Tested-by: Sander Eikelenboom li...@eikelenboom.it
 Signed-off-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
 Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 
 diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
 index 45e94ac..3326204 100644
 --- a/arch/x86/xen/Makefile
 +++ b/arch/x86/xen/Makefile
 @@ -15,7 +15,7 @@ obj-y   := enlighten.o setup.o multicalls.o 
 mmu.o irq.o \
   grant-table.o suspend.o platform-pci-unplug.o \
   p2m.o
  
 -obj-$(CONFIG_FUNCTION_TRACER) += trace.o
 +obj-$(CONFIG_FTRACE) += trace.o
  
  obj-$(CONFIG_SMP)+= smp.o
  obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 
 .. snip of the long compile error..
 
  These build failures are still triggering upstream:
  
   arch/x86/xen/trace.c:44:2: error: array index in initializer not of 
  integer type
   arch/x86/xen/trace.c:44:2: error: (near initialization for 
  ‘xen_hypercall_names’)
   arch/x86/xen/trace.c:45:1: error: ‘__HYPERVISOR_arch_4’ undeclared here 
  (not in a function)
   arch/x86/xen/trace.c:45:2: error: array index in initializer not of 
  integer type
   arch/x86/xen/trace.c:45:2: error: (near initialization for 
  ‘xen_hypercall_names’)
 
 Oh, that I haven't seen. Can you send me the .config for that please.

You can't be trying very hard then.  I see lots of these (but no,
I haven't reported them.  One can grow weary of reporting xen bugs.)


  even after:
  
   b3c4b9825075: xen/tracing: fix compile errors when tracing is disabled.
  
  Btw., that the heck is going on with the commit that introduced the 
  build failure:
  
   commit bd9ddc875b6659f9f74dcfd285c472bc58041abd
   Author: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
   AuthorDate: Mon Jun 20 17:52:13 2011 -0700
   Commit: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com
   CommitDate: Mon Jul 18 15:43:46 2011 -0700
  
  It was apparently rebased shortly before the merge window and sent to 
 
 Well, the rebase I get - it was done on top of the merge that introduced
 the new functionality.
 
  Linus 3 days later, with little to no linux-next testing ...
 
 Hmm It did fix the compile problem.. albeit it created another one.
  
  I'm absolutely unhappy about how the Xen tree is being run. It's 
  using a sloppy, crappy workflow and it is producing crap.
 
 Do you have a manual of how you guys run your workflow?

I just run 30-50 randconfigs per night (cron job).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [Xen-devel] Re: linux-next: Tree for July 25 (xen)

[Randy Dunlap]

On Thu, 4 Aug 2011 18:30:18 -0400 Konrad Rzeszutek Wilk wrote:

   Do you have a manual of how you guys run your workflow?
  
  I just run 30-50 randconfigs per night (cron job).
 
 Ok, do you have an mailing list where you send the output too?

I don't report 100% of what I see.

What I do report goes to linux-next, lkml,  any other relevant
mailing list, and sometimes to individuals as well.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [Xen-devel] Re: linux-next: Tree for July 25 (xen)

[Randy Dunlap]

On Thu, 4 Aug 2011 18:40:20 -0400 Konrad Rzeszutek Wilk wrote:

 On Thu, Aug 04, 2011 at 06:32:59PM -0400, Konrad Rzeszutek Wilk wrote:
 These build failures are still triggering upstream:
 
  arch/x86/xen/trace.c:44:2: error: array index in initializer not of 
 integer type
  arch/x86/xen/trace.c:44:2: error: (near initialization for 
 ‘xen_hypercall_names’)
  arch/x86/xen/trace.c:45:1: error: ‘__HYPERVISOR_arch_4’ undeclared 
 here (not in a function)
  arch/x86/xen/trace.c:45:2: error: array index in initializer not of 
 integer type
  arch/x86/xen/trace.c:45:2: error: (near initialization for 
 ‘xen_hypercall_names’)

Oh, that I haven't seen. Can you send me the .config for that please.
   
   You can't be trying very hard then.  I see lots of these (but no,
  
  Ah, I am getting it now. Thanks for reporting it.
 
 This should do the trick:

OK, I have it building now.  Will do a few builds before I report
back on it.

Thanks.

 
 diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
 index 734beba..520022d 100644
 --- a/arch/x86/xen/trace.c
 +++ b/arch/x86/xen/trace.c
 @@ -1,4 +1,5 @@
  #include linux/ftrace.h
 +#include xen/interface/xen.h
  
  #define N(x) [__HYPERVISOR_##x] = (#x)
  static const char *xen_hypercall_names[] = {
 --


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [Xen-devel] Re: linux-next: Tree for July 25 (xen)

[Randy Dunlap]

On 08/04/11 15:40, Konrad Rzeszutek Wilk wrote:
 On Thu, Aug 04, 2011 at 06:32:59PM -0400, Konrad Rzeszutek Wilk wrote:
 These build failures are still triggering upstream:

  arch/x86/xen/trace.c:44:2: error: array index in initializer not of 
 integer type
  arch/x86/xen/trace.c:44:2: error: (near initialization for 
 ‘xen_hypercall_names’)
  arch/x86/xen/trace.c:45:1: error: ‘__HYPERVISOR_arch_4’ undeclared here 
 (not in a function)
  arch/x86/xen/trace.c:45:2: error: array index in initializer not of 
 integer type
  arch/x86/xen/trace.c:45:2: error: (near initialization for 
 ‘xen_hypercall_names’)

 Oh, that I haven't seen. Can you send me the .config for that please.

 You can't be trying very hard then.  I see lots of these (but no,

 Ah, I am getting it now. Thanks for reporting it.
 
 This should do the trick:

Acked-by: Randy Dunlap rdun...@xenotime.net

Thanks.


 diff --git a/arch/x86/xen/trace.c b/arch/x86/xen/trace.c
 index 734beba..520022d 100644
 --- a/arch/x86/xen/trace.c
 +++ b/arch/x86/xen/trace.c
 @@ -1,4 +1,5 @@
  #include linux/ftrace.h
 +#include xen/interface/xen.h
  
  #define N(x) [__HYPERVISOR_##x] = (#x)
  static const char *xen_hypercall_names[] = {


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 00:38, Arnd Bergmann wrote:
 On Thursday 09 June 2011 01:10:09 Randy Dunlap wrote:
 On Wed, 8 Jun 2011 17:45:54 -0500 Timur Tabi wrote:

 Add the drivers/virt directory, which houses drivers that support
 virtualization environments, and add the Freescale hypervisor management
 driver.

 It can't go in linux/virt or linux/virt/fsl instead?  why drivers/ ?

 or maybe linux/virt should be drivers/virt ?
 
 See discussion for v2 of this patch. I suggested that drivers/firmware and 
 virt/
 as options, the counterarguments were that drivers/firmware is for passive
 firmware as opposed to firmware that acts as a hypervisor, and that virt/ is
 for the host side of hypervisors like kvm, not for guests.

OK, I read that thread.  Didn't see a real consensus there.

If you were not the drivers/misc/ maintainer, would you mind if this
driver lived in drivers/misc/?  I wouldn't.

But it sounds like virt/ needs virt/host/ and virt/guest/ to me.


 The driver in here most closely resembles the xen dom0 model, where a
 priviledged guest controls other guests, but unlike xen there is a single
 driver file, so there is no need to have drivers/fsl-hv directory just
 for this one file. We do have a number of other hypervisors that fit in the
 same category, so they can be added here later.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 7/7] [v4] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 09:36, Timur Tabi wrote:
 Randy Dunlap wrote:
 But it sounds like virt/ needs virt/host/ and virt/guest/ to me.
 
 I'm okay with that idea, except there's a consensus that drivers should be in
 drivers/.
 

Like sound/ ?

but what makes it a driver?

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On Thu, 9 Jun 2011 14:13:14 -0500 Timur Tabi wrote:

 Add the drivers/virt directory, which houses drivers that support
 virtualization environments, and add the Freescale hypervisor management
 driver.
 
 The Freescale hypervisor management driver provides several services to
 drivers and applications related to the Freescale hypervisor:
 
 1. An ioctl interface for querying and managing partitions
 
 2. A file interface to reading incoming doorbells
 
 3. An interrupt handler for shutting down the partition upon receiving the
shutdown doorbell from a manager partition
 
 4. A kernel interface for receiving callbacks when a managed partition
shuts down.
 
 Signed-off-by: Timur Tabi ti...@freescale.com
 ---
  drivers/Kconfig|2 +
  drivers/Makefile   |3 +
  drivers/virt/Kconfig   |   32 ++
  drivers/virt/Makefile  |5 +
  drivers/virt/fsl_hypervisor.c  |  983 
 
  include/linux/Kbuild   |1 +
  include/linux/fsl_hypervisor.h |  231 ++
  7 files changed, 1257 insertions(+), 0 deletions(-)
  create mode 100644 drivers/virt/Kconfig
  create mode 100644 drivers/virt/Makefile
  create mode 100644 drivers/virt/fsl_hypervisor.c
  create mode 100644 include/linux/fsl_hypervisor.h

 diff --git a/include/linux/fsl_hypervisor.h b/include/linux/fsl_hypervisor.h
 new file mode 100644
 index 000..d1ca2b1
 --- /dev/null
 +++ b/include/linux/fsl_hypervisor.h
 @@ -0,0 +1,231 @@

[snip]

 +/**
 + * enum fsl_hv_ioctl_cmd - ioctl commands
 + * @FSL_HV_IOCTL_PARTITION_RESTART: restart another partition
 + * @FSL_HV_IOCTL_PARTITION_GET_STATUS: get a partition's status
 + * @FSL_HV_IOCTL_PARTITION_START: boot another partition
 + * @FSL_HV_IOCTL_PARTITION_STOP: stop this or another partition
 + * @FSL_HV_IOCTL_MEMCPY: copy data from one partition to another
 + * @FSL_HV_IOCTL_DOORBELL: ring a doorbell
 + * @FSL_HV_IOCTL_GETPROP: get a property from another guest's device tree
 + * @FSL_HV_IOCTL_SETPROP: set a property in another guest's device tree
 + *
 + * This enum lists the available ioctl commands for the Freescale hypervisor
 + * management driver.  The meaning
 + */
 +enum fsl_hv_ioctl_cmd {
 + FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
 fsl_hv_ioctl_restart),
 + FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
 fsl_hv_ioctl_status),
 + FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
 + FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
 + FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
 + FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
 + FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
 + FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
 +};

Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with conflict!).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 7/7] [v5] drivers/virt: introduce Freescale hypervisor management driver

[Randy Dunlap]

On 06/09/11 12:47, Timur Tabi wrote:
 Randy Dunlap wrote:
 +enum fsl_hv_ioctl_cmd {
 +  FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct 
 fsl_hv_ioctl_restart),
 +  FSL_HV_IOCTL_PARTITION_GET_STATUS = _IOWR(0, 2, struct 
 fsl_hv_ioctl_status),
 +  FSL_HV_IOCTL_PARTITION_START = _IOWR(0, 3, struct fsl_hv_ioctl_start),
 +  FSL_HV_IOCTL_PARTITION_STOP = _IOWR(0, 4, struct fsl_hv_ioctl_stop),
 +  FSL_HV_IOCTL_MEMCPY = _IOWR(0, 5, struct fsl_hv_ioctl_memcpy),
 +  FSL_HV_IOCTL_DOORBELL = _IOWR(0, 6, struct fsl_hv_ioctl_doorbell),
 +  FSL_HV_IOCTL_GETPROP = _IOWR(0, 7, struct fsl_hv_ioctl_prop),
 +  FSL_HV_IOCTL_SETPROP = _IOWR(0, 8, struct fsl_hv_ioctl_prop),
 +};
 
 Missing an entry in Documentation/ioctl/ioctl-number.txt for 0 (with 
 conflict!).
 
 If I change it from 0, I'm going to break binary compatibility with our apps. 
  I
 agree that maybe I shouldn't have picked 0, but considering how many conflicts
 there already are, I wonder what the point is.  Even if I pick a number that 
 is
 currently not listed in the chart, that doesn't mean that it's actually not
 being used, or that it won't conflict in the future.

Yes, I understood that.

 So is it okay to stick with 0, or do I need to pick a new number?

I wasn't suggesting that you change the 0, just note that it has conflicts,
like other ioctls do.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig

[Randy Dunlap]

On Wed, 4 May 2011 11:53:38 -0700 Greg KH wrote:

 On Wed, May 04, 2011 at 01:44:27PM -0500, H Hartley Sweeten wrote:
  On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:
  
   The vmbus driver dependes on ACPI and PCI subsystems. Change 
   Kconfig to reflect this.
  
   Signed-off-by: K. Y. Srinivasan k...@microsoft.com
   Signed-off-by: Haiyang Zhang haiya...@microsoft.com
   ---
drivers/staging/hv/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
  
   diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
   index 76f0756..5e0c9f6 100644
   --- a/drivers/staging/hv/Kconfig
   +++ b/drivers/staging/hv/Kconfig
   @@ -1,6 +1,6 @@
config HYPERV
 tristate Microsoft Hyper-V client drivers
   - depends on X86  m
   + depends on X86  ACPI  PCI  m
 default n
 help
   Select this option to run Linux as a Hyper-V client operating
  
  ACPI itself depends on PCI.
 
 Still?  I thought that got removed a while ago.

Still.  Len has written in the past that technically there is no such
dependency, but in reality there is, for now at least.  IIRC.


  It also depends on IA64 || X86.  Will the vmbus driver work with IA64?
 
 No.
 
  If so the depends on could just be:
  
  depends on ACPI  m
 
 No, see above for the IA64 reason.
 
  Also, default n is redudant since n is the default anyway.
 
 True, but it doesn't hurt either :)


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/1] Staging: hv: Add the necessary dependencies to hyperv Kconfig

[Randy Dunlap]

On Wed, 4 May 2011 12:39:54 -0700 Greg KH wrote:

 On Wed, May 04, 2011 at 12:33:02PM -0700, Randy Dunlap wrote:
  On Wed, 4 May 2011 11:53:38 -0700 Greg KH wrote:
  
   On Wed, May 04, 2011 at 01:44:27PM -0500, H Hartley Sweeten wrote:
On Wednesday, May 04, 2011 11:52 AM, K. Y. Srinivasan wrote:

 The vmbus driver dependes on ACPI and PCI subsystems. Change 
 Kconfig to reflect this.

 Signed-off-by: K. Y. Srinivasan k...@microsoft.com
 Signed-off-by: Haiyang Zhang haiya...@microsoft.com
 ---
  drivers/staging/hv/Kconfig |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/staging/hv/Kconfig b/drivers/staging/hv/Kconfig
 index 76f0756..5e0c9f6 100644
 --- a/drivers/staging/hv/Kconfig
 +++ b/drivers/staging/hv/Kconfig
 @@ -1,6 +1,6 @@
  config HYPERV
   tristate Microsoft Hyper-V client drivers
 - depends on X86  m
 + depends on X86  ACPI  PCI  m
   default n
   help
 Select this option to run Linux as a Hyper-V client operating

ACPI itself depends on PCI.
   
   Still?  I thought that got removed a while ago.
  
  Still.  Len has written in the past that technically there is no such
  dependency, but in reality there is, for now at least.  IIRC.
 
 Ok, but then we should still say we depend on PCI to handle if/when ACPI
 removes that dependancy in the future.  It doesn't hurt here at all.

Yes, I prefer that also.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[PATCH] xen: fix p2m section mismatches

[Randy Dunlap]

From: Randy Dunlap randy.dun...@oracle.com

Fix section mismatch warnings:
set_phys_range_identity() is called by __init xen_set_identity(),
so also mark set_phys_range_identity() as __init.
then:
__early_alloc_p2m() is called set_phys_range_identity(), so also mark
__early_alloc_p2m() as __init.

WARNING: arch/x86/built-in.o(.text+0x7856): Section mismatch in reference from 
the function __early_alloc_p2m() to the function .init.text:extend_brk()
The function __early_alloc_p2m() references
the function __init extend_brk().
This is often because __early_alloc_p2m lacks a __init 
annotation or the annotation of extend_brk is wrong.

WARNING: arch/x86/built-in.o(.text+0x7967): Section mismatch in reference from 
the function set_phys_range_identity() to the function .init.text:extend_brk()
The function set_phys_range_identity() references
the function __init extend_brk().
This is often because set_phys_range_identity lacks a __init 
annotation or the annotation of extend_brk is wrong.

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
 arch/x86/xen/p2m.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.38-git13.orig/arch/x86/xen/p2m.c
+++ linux-2.6.38-git13/arch/x86/xen/p2m.c
@@ -497,7 +497,7 @@ static bool alloc_p2m(unsigned long pfn)
return true;
 }
 
-bool __early_alloc_p2m(unsigned long pfn)
+bool __init __early_alloc_p2m(unsigned long pfn)
 {
unsigned topidx, mididx, idx;
 
@@ -530,7 +530,7 @@ bool __early_alloc_p2m(unsigned long pfn
}
return idx != 0;
 }
-unsigned long set_phys_range_identity(unsigned long pfn_s,
+unsigned long __init set_phys_range_identity(unsigned long pfn_s,
  unsigned long pfn_e)
 {
unsigned long pfn;
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization