* Re: [PATCHv2 ipsec-next] xfrm: remove the unnecessary .net_exit for xfrmi
From: Steffen Klassert @ 2019-09-17 9:02 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem
In-Reply-To: <0e9b72a6caf695dd99c02bd223168897977daaef.1568017810.git.lucien.xin@gmail.com>
On Mon, Sep 09, 2019 at 04:30:10PM +0800, Xin Long wrote:
> The xfrm_if(s) on each netns can be deleted when its xfrmi dev is
> deleted. xfrmi dev's removal can happen when:
>
> a. netns is being removed and all xfrmi devs will be deleted.
>
> b. rtnl_link_unregister(&xfrmi_link_ops) in xfrmi_fini() when
> xfrm_interface.ko is being unloaded.
>
> So there's no need to use xfrmi_exit_net() to clean any xfrm_if up.
>
> v1->v2:
> - Fix some changelog.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
I've queued this for applying until after the merge window,
no need to resend.
Thanks!
^ permalink raw reply
* Re: [PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Jes Sorensen @ 2019-09-17 9:19 UTC (permalink / raw)
To: Chris Chiu, kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, linux, Daniel Drake
In-Reply-To: <20190917074007.92259-1-chiu@endlessm.com>
On 9/17/19 3:40 AM, Chris Chiu wrote:
> We have 3 laptops which connect the wifi by the same RTL8723BU.
> The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> They have the same problem with the in-kernel rtl8xxxu driver, the
> iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> Nevertheless, the signal strength is reported as around -40dBm,
> which is quite good. From the wireshark capture, the tx rate for each
> data and qos data packet is only 1Mbps. Compare to the Realtek driver
> at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
> ~12Mbps or better. The signal strength is reported similarly around
> -40dBm. That's why we want to improve.
>
> After reading the source code of the rtl8xxxu driver and Realtek's, the
> major difference is that Realtek's driver has a watchdog which will keep
> monitoring the signal quality and updating the rate mask just like the
> rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> And this kind of watchdog also exists in rtlwifi driver of some specific
> chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> the same member function named dm_watchdog and will invoke the
> corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> mask.
>
> With this commit, the tx rate of each data and qos data packet will
> be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
> to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> the lowest rate from the rate mask and explains why the tx rate of
> data and qos data is always lowest 1Mbps because the default rate mask
> passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
> and MCS rate. However, with Realtek's driver, the tx rate observed from
> wireshark under the same condition is almost 65Mbps or 72Mbps, which
> indicating that rtl8xxxu could still be further improved.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
> Reviewed-by: Daniel Drake <drake@endlessm.com>
I am still traveling after Plumbers and don't have my 8723bu dongles
with me, but I'd say this looks good.
Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Jes
^ permalink raw reply
* [PATCH net] net/sched: act_sample: don't push mac header on ip6gre ingress
From: Davide Caratti @ 2019-09-17 9:30 UTC (permalink / raw)
To: Jiri Pirko, Cong Wang, Jamal Hadi Salim, David S. Miller, netdev
Cc: Yotam Gigi
current 'sample' action doesn't push the mac header of ingress packets if
they are received by a layer 3 tunnel (like gre or sit); but it forgot to
check for gre over ipv6, so the following script:
# tc q a dev $d clsact
# tc f a dev $d ingress protocol ip flower ip_proto icmp action sample \
> group 100 rate 1
# psample -v -g 100
dumps everything, including outer header and mac, when $d is a gre tunnel
over ipv6. Fix this adding a missing label for ARPHRD_IP6GRE devices.
Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_sample.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sched/act_sample.c b/net/sched/act_sample.c
index 10229124a992..86344fd2ff1f 100644
--- a/net/sched/act_sample.c
+++ b/net/sched/act_sample.c
@@ -146,6 +146,7 @@ static bool tcf_sample_dev_ok_push(struct net_device *dev)
case ARPHRD_TUNNEL6:
case ARPHRD_SIT:
case ARPHRD_IPGRE:
+ case ARPHRD_IP6GRE:
case ARPHRD_VOID:
case ARPHRD_NONE:
return false;
--
2.21.0
^ permalink raw reply related
* Re: memory leak in cfserl_create
From: syzbot @ 2019-09-17 9:43 UTC (permalink / raw)
To: alexios.zavras, allison, davem, linux-kernel, netdev, rfontana,
swinslow, syzkaller-bugs, tglx
In-Reply-To: <00000000000053d7e9058a97f4ca@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: cef72982 Merge tag 'armsoc-dt' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1042ac45600000
kernel config: https://syzkaller.appspot.com/x/.config?x=779aef2b86e19d75
dashboard link: https://syzkaller.appspot.com/bug?extid=7ec324747ce876a29db6
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16ef2331600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f0c091600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7ec324747ce876a29db6@syzkaller.appspotmail.com
BUG: memory leak
unreferenced object 0xffff88810a3b7380 (size 128):
comm "syz-executor868", pid 7100, jiffies 4294943513 (age 21.740s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004f492e65>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000004f492e65>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000004f492e65>] slab_alloc mm/slab.c:3319 [inline]
[<000000004f492e65>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000478a63c3>] kmalloc include/linux/slab.h:552 [inline]
[<00000000478a63c3>] kzalloc include/linux/slab.h:748 [inline]
[<00000000478a63c3>] cfserl_create+0x24/0x76 net/caif/cfserl.c:36
[<0000000097ca7138>] caif_device_notify+0x347/0x3bc
net/caif/caif_dev.c:388
[<0000000078bf2b15>] notifier_call_chain+0x66/0xb0 kernel/notifier.c:95
[<000000001a557d7e>] __raw_notifier_call_chain kernel/notifier.c:396
[inline]
[<000000001a557d7e>] raw_notifier_call_chain+0x2e/0x40
kernel/notifier.c:403
[<00000000de93bbde>] call_netdevice_notifiers_info+0x33/0x70
net/core/dev.c:1749
[<0000000004467db0>] call_netdevice_notifiers_extack
net/core/dev.c:1761 [inline]
[<0000000004467db0>] call_netdevice_notifiers net/core/dev.c:1775
[inline]
[<0000000004467db0>] register_netdevice+0x445/0x610 net/core/dev.c:8757
[<000000007e97ac10>] ldisc_open+0x1f7/0x350
drivers/net/caif/caif_serial.c:359
[<000000003eb33d8f>] tty_ldisc_open.isra.0+0x44/0x70
drivers/tty/tty_ldisc.c:469
[<00000000ded1208b>] tty_set_ldisc+0x149/0x240
drivers/tty/tty_ldisc.c:596
[<00000000df974937>] tiocsetd drivers/tty/tty_io.c:2334 [inline]
[<00000000df974937>] tty_ioctl+0x366/0xa30 drivers/tty/tty_io.c:2594
[<00000000739f048c>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000739f048c>] file_ioctl fs/ioctl.c:509 [inline]
[<00000000739f048c>] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696
[<00000000e122cb0c>] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713
[<0000000067a2ba29>] __do_sys_ioctl fs/ioctl.c:720 [inline]
[<0000000067a2ba29>] __se_sys_ioctl fs/ioctl.c:718 [inline]
[<0000000067a2ba29>] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718
[<0000000071a2e1c5>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000c342e2c0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810a3b7400 (size 128):
comm "syz-executor868", pid 7101, jiffies 4294943519 (age 21.680s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004f492e65>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000004f492e65>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000004f492e65>] slab_alloc mm/slab.c:3319 [inline]
[<000000004f492e65>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000478a63c3>] kmalloc include/linux/slab.h:552 [inline]
[<00000000478a63c3>] kzalloc include/linux/slab.h:748 [inline]
[<00000000478a63c3>] cfserl_create+0x24/0x76 net/caif/cfserl.c:36
[<0000000097ca7138>] caif_device_notify+0x347/0x3bc
net/caif/caif_dev.c:388
[<0000000078bf2b15>] notifier_call_chain+0x66/0xb0 kernel/notifier.c:95
[<000000001a557d7e>] __raw_notifier_call_chain kernel/notifier.c:396
[inline]
[<000000001a557d7e>] raw_notifier_call_chain+0x2e/0x40
kernel/notifier.c:403
[<00000000de93bbde>] call_netdevice_notifiers_info+0x33/0x70
net/core/dev.c:1749
[<0000000004467db0>] call_netdevice_notifiers_extack
net/core/dev.c:1761 [inline]
[<0000000004467db0>] call_netdevice_notifiers net/core/dev.c:1775
[inline]
[<0000000004467db0>] register_netdevice+0x445/0x610 net/core/dev.c:8757
[<000000007e97ac10>] ldisc_open+0x1f7/0x350
drivers/net/caif/caif_serial.c:359
[<000000003eb33d8f>] tty_ldisc_open.isra.0+0x44/0x70
drivers/tty/tty_ldisc.c:469
[<00000000ded1208b>] tty_set_ldisc+0x149/0x240
drivers/tty/tty_ldisc.c:596
[<00000000df974937>] tiocsetd drivers/tty/tty_io.c:2334 [inline]
[<00000000df974937>] tty_ioctl+0x366/0xa30 drivers/tty/tty_io.c:2594
[<00000000739f048c>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000739f048c>] file_ioctl fs/ioctl.c:509 [inline]
[<00000000739f048c>] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696
[<00000000e122cb0c>] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713
[<0000000067a2ba29>] __do_sys_ioctl fs/ioctl.c:720 [inline]
[<0000000067a2ba29>] __se_sys_ioctl fs/ioctl.c:718 [inline]
[<0000000067a2ba29>] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718
[<0000000071a2e1c5>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000c342e2c0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810a3b7780 (size 128):
comm "syz-executor868", pid 7138, jiffies 4294943524 (age 21.630s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000004f492e65>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000004f492e65>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000004f492e65>] slab_alloc mm/slab.c:3319 [inline]
[<000000004f492e65>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000478a63c3>] kmalloc include/linux/slab.h:552 [inline]
[<00000000478a63c3>] kzalloc include/linux/slab.h:748 [inline]
[<00000000478a63c3>] cfserl_create+0x24/0x76 net/caif/cfserl.c:36
[<0000000097ca7138>] caif_device_notify+0x347/0x3bc
net/caif/caif_dev.c:388
[<0000000078bf2b15>] notifier_call_chain+0x66/0xb0 kernel/notifier.c:95
[<000000001a557d7e>] __raw_notifier_call_chain kernel/notifier.c:396
[inline]
[<000000001a557d7e>] raw_notifier_call_chain+0x2e/0x40
kernel/notifier.c:403
[<00000000de93bbde>] call_netdevice_notifiers_info+0x33/0x70
net/core/dev.c:1749
[<0000000004467db0>] call_netdevice_notifiers_extack
net/core/dev.c:1761 [inline]
[<0000000004467db0>] call_netdevice_notifiers net/core/dev.c:1775
[inline]
[<0000000004467db0>] register_netdevice+0x445/0x610 net/core/dev.c:8757
[<000000007e97ac10>] ldisc_open+0x1f7/0x350
drivers/net/caif/caif_serial.c:359
[<000000003eb33d8f>] tty_ldisc_open.isra.0+0x44/0x70
drivers/tty/tty_ldisc.c:469
[<00000000ded1208b>] tty_set_ldisc+0x149/0x240
drivers/tty/tty_ldisc.c:596
[<00000000df974937>] tiocsetd drivers/tty/tty_io.c:2334 [inline]
[<00000000df974937>] tty_ioctl+0x366/0xa30 drivers/tty/tty_io.c:2594
[<00000000739f048c>] vfs_ioctl fs/ioctl.c:46 [inline]
[<00000000739f048c>] file_ioctl fs/ioctl.c:509 [inline]
[<00000000739f048c>] do_vfs_ioctl+0x62a/0x810 fs/ioctl.c:696
[<00000000e122cb0c>] ksys_ioctl+0x86/0xb0 fs/ioctl.c:713
[<0000000067a2ba29>] __do_sys_ioctl fs/ioctl.c:720 [inline]
[<0000000067a2ba29>] __se_sys_ioctl fs/ioctl.c:718 [inline]
[<0000000067a2ba29>] __x64_sys_ioctl+0x1e/0x30 fs/ioctl.c:718
[<0000000071a2e1c5>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000c342e2c0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
executing program
executing program
executing program
executing program
^ permalink raw reply
* Re: [PATCH v2] ixgbe: Use memset_explicit directly in crypto cases
From: Sergei Shtylyov @ 2019-09-17 9:59 UTC (permalink / raw)
To: zhong jiang, jakub.kicinski, davem
Cc: anna.schumaker, trond.myklebust, netdev, linux-kernel
In-Reply-To: <1568691910-21442-1-git-send-email-zhongjiang@huawei.com>
Hello!
On 17.09.2019 6:45, zhong jiang wrote:
> It's better to use memset_explicit() to replace memset() in crypto cases.
But you're using memzero_explicit() below?
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> index 31629fc..7e4f32f 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> @@ -960,10 +960,10 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
> return 0;
>
> err_aead:
> - memset(xs->aead, 0, sizeof(*xs->aead));
> + memzero_explicit(xs->aead, sizeof(*xs->aead));
> kfree(xs->aead);
> err_xs:
> - memset(xs, 0, sizeof(*xs));
> + memzero_explicit(xs, sizeof(*xs));
> kfree(xs);
> err_out:
> msgbuf[1] = err;
> @@ -1049,7 +1049,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
> ixgbe_ipsec_del_sa(xs);
>
> /* remove the xs that was made-up in the add request */
> - memset(xs, 0, sizeof(*xs));
> + memzero_explicit(xs, sizeof(*xs));
> kfree(xs);
>
> return 0;
MBR, Sergei
^ permalink raw reply
* [PATCH] net: stmmac: Fix ASSERT_RTNL() warning on suspend/resume
From: Loys Ollivier @ 2019-09-17 10:02 UTC (permalink / raw)
To: Russell King, Maxime Coquelin
Cc: Loys Ollivier, Jose Abreu, David S. Miller, Giuseppe Cavallaro,
Alexandre Torgue, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
rtnl_lock needs to be taken before calling phylink_start/stop to lock the
network stack.
Fix ASSERT_RTNL() warnings by protecting such calls with lock/unlock.
Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Signed-off-by: Loys Ollivier <lollivier@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fd54c7c87485..485f33f57b43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4451,7 +4451,9 @@ int stmmac_suspend(struct device *dev)
if (!ndev || !netif_running(ndev))
return 0;
+ rtnl_lock();
phylink_stop(priv->phylink);
+ rtnl_unlock();
mutex_lock(&priv->lock);
@@ -4560,7 +4562,9 @@ int stmmac_resume(struct device *dev)
mutex_unlock(&priv->lock);
+ rtnl_lock();
phylink_start(priv->phylink);
+ rtnl_unlock();
return 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 1/5] mdev: Introduce sha1 based mdev alias
From: Cornelia Huck @ 2019-09-17 10:03 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-2-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:32 -0500
Parav Pandit <parav@mellanox.com> wrote:
> Some vendor drivers want an identifier for an mdev device that is
> shorter than the UUID, due to length restrictions in the consumers of
> that identifier.
>
> Add a callback that allows a vendor driver to request an alias of a
> specified length to be generated for an mdev device. If generated,
> that alias is checked for collisions.
>
> It is an optional attribute.
> mdev alias is generated using sha1 from the mdev name.
>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
>
> ---
> Changelog:
> v1->v2:
> - Kept mdev_device naturally aligned
> - Added error checking for crypt_*() calls
> - Corrected a typo from 'and' to 'an'
> - Changed return type of generate_alias() from int to char*
> v0->v1:
> - Moved alias length check outside of the parent lock
> - Moved alias and digest allocation from kvzalloc to kzalloc
> - &alias[0] changed to alias
> - alias_length check is nested under get_alias_length callback check
> - Changed comments to start with an empty line
> - Fixed cleaunup of hash if mdev_bus_register() fails
> - Added comment where alias memory ownership is handed over to mdev device
> - Updated commit log to indicate motivation for this feature
> ---
> drivers/vfio/mdev/mdev_core.c | 123 ++++++++++++++++++++++++++++++-
> drivers/vfio/mdev/mdev_private.h | 5 +-
> drivers/vfio/mdev/mdev_sysfs.c | 13 ++--
> include/linux/mdev.h | 4 +
> 4 files changed, 135 insertions(+), 10 deletions(-)
(...)
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index 0ce30ca78db0..f036fe9854ee 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -72,6 +72,9 @@ struct device *mdev_get_iommu_device(struct device *dev);
> * @mmap: mmap callback
> * @mdev: mediated device structure
> * @vma: vma structure
> + * @get_alias_length: Generate alias for the mdevs of this parent based on the
> + * mdev device name when it returns non zero alias length.
"Optional: If a non-zero alias length is returned, generate an alias
for this parent's mdevs based upon the mdev device name."
?
> + * It is optional.
> * Parent device that support mediated device should be registered with mdev
> * module with mdev_parent_ops structure.
> **/
> @@ -92,6 +95,7 @@ struct mdev_parent_ops {
> long (*ioctl)(struct mdev_device *mdev, unsigned int cmd,
> unsigned long arg);
> int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
> + unsigned int (*get_alias_length)(void);
> };
>
> /* interface for exporting mdev supported type attributes */
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH v3 2/5] mdev: Make mdev alias unique among all mdevs
From: Cornelia Huck @ 2019-09-17 10:04 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-3-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:33 -0500
Parav Pandit <parav@mellanox.com> wrote:
> Mdev alias should be unique among all the mdevs, so that when such alias
> is used by the mdev users to derive other objects, there is no
> collision in a given system.
>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
>
> ---
> Changelog:
> v2->v3:
> - Changed strcmp() ==0 to !strcmp()
> v1->v2:
> - Moved alias NULL check at beginning
> v0->v1:
> - Fixed inclusiong of alias for NULL check
> - Added ratelimited debug print for sha1 hash collision error
> ---
> drivers/vfio/mdev/mdev_core.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH v3 3/5] mdev: Expose mdev alias in sysfs tree
From: Cornelia Huck @ 2019-09-17 10:08 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-4-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:34 -0500
Parav Pandit <parav@mellanox.com> wrote:
> Expose the optional alias for an mdev device as a sysfs attribute.
> This way, userspace tools such as udev may make use of the alias, for
> example to create a netdevice name for the mdev.
>
> Updated documentation for optional read only sysfs attribute.
>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
>
> ---
> Changelog:
> v2->v3:
> - Merged sysfs documentation patch with sysfs addition
> - Added more description for alias return value
> v0->v1:
> - Addressed comments from Cornelia Huck
> - Updated commit description
> ---
> Documentation/driver-api/vfio-mediated-device.rst | 9 +++++++++
> drivers/vfio/mdev/mdev_sysfs.c | 13 +++++++++++++
> 2 files changed, 22 insertions(+)
>
(...)
> @@ -281,6 +282,14 @@ Example::
>
> # echo 1 > /sys/bus/mdev/devices/$mdev_UUID/remove
>
> +* alias (read only, optional)
> +Whenever a parent requested to generate an alias, each mdev device of such
s/such/that/
> +parent is assigned unique alias by the mdev core.
s/unique alias/a unique alias/
> +This file shows the alias of the mdev device.
> +
> +Reading file either returns valid alias when assigned or returns error code
s/file/this file/
s/valid alias/a valid alias/
s/error code/the error code/
> +-EOPNOTSUPP when unsupported.
> +
> Mediated device Hot plug
> ------------------------
With the nits above fixed,
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH v3 4/5] mdev: Introduce an API mdev_alias
From: Cornelia Huck @ 2019-09-17 10:10 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-5-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:35 -0500
Parav Pandit <parav@mellanox.com> wrote:
> Introduce an API mdev_alias() to provide access to optionally generated
> alias.
>
> Signed-off-by: Parav Pandit <parav@mellanox.com>
> ---
> drivers/vfio/mdev/mdev_core.c | 12 ++++++++++++
> include/linux/mdev.h | 1 +
> 2 files changed, 13 insertions(+)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* RE: [PATCH] net: stmmac: Fix ASSERT_RTNL() warning on suspend/resume
From: Jose Abreu @ 2019-09-17 10:12 UTC (permalink / raw)
To: Loys Ollivier, Russell King, Maxime Coquelin
Cc: David S. Miller, Giuseppe Cavallaro, Alexandre Torgue,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1568714556-25024-1-git-send-email-lollivier@baylibre.com>
From: Loys Ollivier <lollivier@baylibre.com>
Date: Sep/17/2019, 11:02:36 (UTC+00:00)
> rtnl_lock needs to be taken before calling phylink_start/stop to lock the
> network stack.
> Fix ASSERT_RTNL() warnings by protecting such calls with lock/unlock.
>
> Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
> Signed-off-by: Loys Ollivier <lollivier@baylibre.com>
I already sent a fix for this. Please see in -net:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/driv
ers/net/ethernet/stmicro/stmmac?id=19e13cb27b998ff49f07e399b5871bfe5ba7e3
f0
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH v3 0/5] Introduce variable length mdev alias
From: Cornelia Huck @ 2019-09-17 10:13 UTC (permalink / raw)
To: Parav Pandit
Cc: alex.williamson, jiri, kwankhede, davem, kvm, linux-kernel,
netdev
In-Reply-To: <20190902042436.23294-1-parav@mellanox.com>
On Sun, 1 Sep 2019 23:24:31 -0500
Parav Pandit <parav@mellanox.com> wrote:
> To have consistent naming for the netdevice of a mdev and to have
> consistent naming of the devlink port [1] of a mdev, which is formed using
> phys_port_name of the devlink port, current UUID is not usable because
> UUID is too long.
>
> UUID in string format is 36-characters long and in binary 128-bit.
> Both formats are not able to fit within 15 characters limit of netdev
> name.
>
> It is desired to have mdev device naming consistent using UUID.
> So that widely used user space framework such as ovs [2] can make use
> of mdev representor in similar way as PCIe SR-IOV VF and PF representors.
>
> Hence,
> (a) mdev alias is created which is derived using sha1 from the mdev name.
> (b) Vendor driver describes how long an alias should be for the child mdev
> created for a given parent.
> (c) Mdev aliases are unique at system level.
> (d) alias is created optionally whenever parent requested.
> This ensures that non networking mdev parents can function without alias
> creation overhead.
>
> This design is discussed at [3].
>
> An example systemd/udev extension will have,
>
> 1. netdev name created using mdev alias available in sysfs.
>
> mdev UUID=83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
> mdev 12 character alias=cd5b146a80a5
>
> netdev name of this mdev = enmcd5b146a80a5
> Here en = Ethernet link
> m = mediated device
>
> 2. devlink port phys_port_name created using mdev alias.
> devlink phys_port_name=pcd5b146a80a5
>
> This patchset enables mdev core to maintain unique alias for a mdev.
>
> Patch-1 Introduces mdev alias using sha1.
> Patch-2 Ensures that mdev alias is unique in a system.
> Patch-3 Exposes mdev alias in a sysfs hirerchy, update Documentation
> Patch-4 Introduces mdev_alias() API.
> Patch-5 Extends mtty driver to optionally provide alias generation.
> This also enables to test UUID based sha1 collision and trigger
> error handling for duplicate sha1 results.
>
> [1] http://man7.org/linux/man-pages/man8/devlink-port.8.html
> [2] https://docs.openstack.org/os-vif/latest/user/plugins/ovs.html
> [3] https://patchwork.kernel.org/cover/11084231/
>
> ---
> Changelog:
> v2->v3:
> - Addressed comment from Yunsheng Lin
> - Changed strcmp() ==0 to !strcmp()
> - Addressed comment from Cornelia Hunk
> - Merged sysfs Documentation patch with syfs patch
> - Added more description for alias return value
> v1->v2:
> - Corrected a typo from 'and' to 'an'
> - Addressed comments from Alex Williamson
> - Kept mdev_device naturally aligned
> - Added error checking for crypt_*() calls
> - Moved alias NULL check at beginning
> - Added mdev_alias() API
> - Updated mtty driver to show example mdev_alias() usage
> - Changed return type of generate_alias() from int to char*
> v0->v1:
> - Addressed comments from Alex Williamson, Cornelia Hunk and Mark Bloch
> - Moved alias length check outside of the parent lock
> - Moved alias and digest allocation from kvzalloc to kzalloc
> - &alias[0] changed to alias
> - alias_length check is nested under get_alias_length callback check
> - Changed comments to start with an empty line
> - Added comment where alias memory ownership is handed over to mdev device
> - Fixed cleaunup of hash if mdev_bus_register() fails
> - Updated documentation for new sysfs alias file
> - Improved commit logs to make description more clear
> - Fixed inclusiong of alias for NULL check
> - Added ratelimited debug print for sha1 hash collision error
>
> Parav Pandit (5):
> mdev: Introduce sha1 based mdev alias
> mdev: Make mdev alias unique among all mdevs
> mdev: Expose mdev alias in sysfs tree
> mdev: Introduce an API mdev_alias
> mtty: Optionally support mtty alias
>
> .../driver-api/vfio-mediated-device.rst | 9 ++
> drivers/vfio/mdev/mdev_core.c | 142 +++++++++++++++++-
> drivers/vfio/mdev/mdev_private.h | 5 +-
> drivers/vfio/mdev/mdev_sysfs.c | 26 +++-
> include/linux/mdev.h | 5 +
> samples/vfio-mdev/mtty.c | 13 ++
> 6 files changed, 190 insertions(+), 10 deletions(-)
>
The patches on their own look sane (and I gave my R-b), but the
consumer of this new API should be ready before this is merged, as
already discussed below.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 09/14] samples: bpf: makefile: use own flags but not host when cross compile
From: Sergei Shtylyov @ 2019-09-17 10:14 UTC (permalink / raw)
To: Ivan Khoronzhuk, ast, daniel, yhs, davem, jakub.kicinski, hawk,
john.fastabend
Cc: linux-kernel, netdev, bpf, clang-built-linux
In-Reply-To: <20190916105433.11404-10-ivan.khoronzhuk@linaro.org>
Hello!
On 16.09.2019 13:54, Ivan Khoronzhuk wrote:
> While compile natively, the hosts cflags and ldflags are equal to ones
Compiling. Host's.
> used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should
> have own, used for target arch. While verification, for arm, arm64 and
> x86_64 the following flags were used alsways:
>
> -Wall
> -O2
> -fomit-frame-pointer
> -Wmissing-prototypes
> -Wstrict-prototypes
>
> So, add them as they were verified and used before adding
> Makefile.target, but anyway limit it only for cross compile options as
> for host can be some configurations when another options can be used,
> So, for host arch samples left all as is, it allows to avoid potential
> option mistmatches for existent environments.
Mismatches.
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
[...]
MBR, Sergei
^ permalink raw reply
* RE: -Wsizeof-array-div warnings in ethernet drivers
From: David Laight @ 2019-09-17 10:36 UTC (permalink / raw)
To: 'Jose Abreu', Nathan Chancellor, Tom Lendacky,
Giuseppe Cavallaro, Alexandre Torgue, David S. Miller
Cc: Nick Desaulniers, Ilie Halip, David Bolvansky,
netdev@vger.kernel.org, clang-built-linux@googlegroups.com
In-Reply-To: <BN8PR12MB3266AFAFF3FAAA9C10FB1C1FD38F0@BN8PR12MB3266.namprd12.prod.outlook.com>
From: Jose Abreu
> Sent: 17 September 2019 08:59
> From: Nathan Chancellor <natechancellor@gmail.com>
> Date: Sep/17/2019, 08:32:32 (UTC+00:00)
>
> > Hi all,
> >
> > Clang recently added a new diagnostic in r371605, -Wsizeof-array-div,
> > that tries to warn when sizeof(X) / sizeof(Y) does not compute the
> > number of elements in an array X (i.e., sizeof(Y) is wrong). See that
> > commit for more details:
...
> > ../drivers/net/ethernet/amd/xgbe/xgbe-dev.c:361:49: warning: expression
> > does not compute the number of elements in this array; element type is
> > 'u8' (aka 'unsigned char'), not 'u32' (aka 'unsigned int')
> > [-Wsizeof-array-div]
> > unsigned int key_regs = sizeof(pdata->rss_key) / sizeof(u32);
> > ~~~~~~~~~~~~~~ ^
...
> > What is the reasoning behind having the key being an array of u8s but
> > seemlingly converting it into an array of u32s? It's not immediately
> > apparent from reading over the code but I am not familiar with it so I
> > might be making a mistake. I assume this is intentional? If so, the
> > warning can be silenced and we'll send patches to do so but we want to
> > make sure we aren't actually papering over a mistake.
>
> This is because we write 32 bits at a time to the reg but internally the
> driver uses 8 bits to store the array. If you look at
> dwxgmac2_rss_configure() you'll see that cfg->key is casted to u32 which
> is the value we use in HW writes. Then the for loop just does the math
> to check how many u32's has to write.
That stinks of a possible misaligned data access.....
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH bpf-next] i40e: fix xdp handle calculations
From: Maxim Mikityanskiy @ 2019-09-17 10:48 UTC (permalink / raw)
To: Kevin Laatz, bjorn.topel
Cc: maximmi, netdev, ast, daniel, magnus.karlsson, jonathan.lemon,
bruce.richardson, ciara.loftus, bpf, intel-wired-lan
In-Reply-To: <20190905011144.3513-1-kevin.laatz@intel.com>
On Thu, Sep 5, 2019 at 4:11 AM Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> Currently, we don't add headroom to the handle in i40e_zca_free,
> i40e_alloc_buffer_slow_zc and i40e_alloc_buffer_zc. The addition of the
> headroom to the handle was removed in
> commit 2f86c806a8a8 ("i40e: modify driver for handling offsets"),
Hi, it looks to me that headroom is still broken after this commit.
i40e_run_xdp_zc adds it a second time, i.e.:
1. xdp->handle already has the headroom added (after this patch).
2. bpf_prog_run_xdp(...);
3. u64 offset = umem->headroom;
offset += xdp->data - xdp->data_hard_start;
xdp->handle = xsk_umem_adjust_offset(umem, xdp->handle, offset);
Step 3 adds the headroom one extra time.
I didn't look at ixgbe, it might also need to be fixed.
> which
> will break things when headroom is non-zero. This patch fixes this and uses
> xsk_umem_adjust_offset to add it appropritely based on the mode being run.
>
> Fixes: 2f86c806a8a8 ("i40e: modify driver for handling offsets")
> Reported-by: Bjorn Topel <bjorn.topel@intel.com>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> Acked-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> index eaca6162a6e6..0373bc6c7e61 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> @@ -267,7 +267,7 @@ static bool i40e_alloc_buffer_zc(struct i40e_ring *rx_ring,
> bi->addr = xdp_umem_get_data(umem, handle);
> bi->addr += hr;
>
> - bi->handle = handle;
> + bi->handle = xsk_umem_adjust_offset(umem, handle, umem->headroom);
>
> xsk_umem_discard_addr(umem);
> return true;
> @@ -304,7 +304,7 @@ static bool i40e_alloc_buffer_slow_zc(struct i40e_ring *rx_ring,
> bi->addr = xdp_umem_get_data(umem, handle);
> bi->addr += hr;
>
> - bi->handle = handle;
> + bi->handle = xsk_umem_adjust_offset(umem, handle, umem->headroom);
>
> xsk_umem_discard_addr_rq(umem);
> return true;
> @@ -469,7 +469,8 @@ void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
> bi->addr = xdp_umem_get_data(rx_ring->xsk_umem, handle);
> bi->addr += hr;
>
> - bi->handle = (u64)handle;
> + bi->handle = xsk_umem_adjust_offset(rx_ring->xsk_umem, (u64)handle,
> + rx_ring->xsk_umem->headroom);
> }
>
> /**
^ permalink raw reply
* Re: [PATCH bpf-next] i40e: fix xdp handle calculations
From: Björn Töpel @ 2019-09-17 10:54 UTC (permalink / raw)
To: Maxim Mikityanskiy, Kevin Laatz
Cc: maximmi, netdev, ast, daniel, magnus.karlsson, jonathan.lemon,
bruce.richardson, ciara.loftus, bpf, intel-wired-lan
In-Reply-To: <CAKErNvpe3htU-ETe0y0XQ=SwY047qc3Z3=aHN6g2BbkoGHNNUQ@mail.gmail.com>
On 2019-09-17 12:48, Maxim Mikityanskiy wrote:
> Hi, it looks to me that headroom is still broken after this commit.
> i40e_run_xdp_zc adds it a second time, i.e.:
Indeed, but Ciara fixed that in this series [1]. Thanks for reviewing
the patch!
Cheers,
Björn
[1]
https://lore.kernel.org/bpf/20190913103948.32053-1-ciara.loftus@intel.com/
^ permalink raw reply
* Re: [PATCH v7 6/7] nfc: pn533: Add autopoll capability
From: Lars Poeschel @ 2019-09-17 10:55 UTC (permalink / raw)
To: David Miller
Cc: allison, keescook, opensource, swinslow, gregkh, gustavo, tglx,
kstewart, netdev, linux-kernel, johan
In-Reply-To: <20190911.101759.1557703938346599792.davem@davemloft.net>
On Wed, Sep 11, 2019 at 10:17:59AM +0200, David Miller wrote:
> From: Lars Poeschel <poeschel@lemonage.de>
> Date: Tue, 10 Sep 2019 11:34:12 +0200
>
> > +static int pn533_autopoll_complete(struct pn533 *dev, void *arg,
> > + struct sk_buff *resp)
> > +{
> > + u8 nbtg;
> > + int rc;
> > + struct pn532_autopoll_resp *apr;
> > + struct nfc_target nfc_tgt;
>
> Need reverse christmas tree here.
See below.
> > @@ -1534,6 +1655,7 @@ static int pn533_start_poll(struct nfc_dev *nfc_dev,
> > struct pn533_poll_modulations *cur_mod;
> > u8 rand_mod;
> > int rc;
> > + struct sk_buff *skb;
>
> Likewise.
I will do a v8 with these changes soon.
^ permalink raw reply
* Re: [PATCH v7 5/7] nfc: pn533: add UART phy driver
From: Lars Poeschel @ 2019-09-17 10:56 UTC (permalink / raw)
To: David Miller
Cc: gregkh, tglx, kstewart, swinslow, allison, linux-kernel, netdev,
johan, Claudiu.Beznea
In-Reply-To: <20190911.101732.1453519960272118746.davem@davemloft.net>
On Wed, Sep 11, 2019 at 10:17:32AM +0200, David Miller wrote:
> From: Lars Poeschel <poeschel@lemonage.de>
> Date: Tue, 10 Sep 2019 11:33:50 +0200
>
> > +static int pn532_uart_send_ack(struct pn533 *dev, gfp_t flags)
> > +{
> > + struct pn532_uart_phy *pn532 = dev->phy;
> > + /* spec 7.1.1.3: Preamble, SoPC (2), ACK Code (2), Postamble */
> > + static const u8 ack[PN533_STD_FRAME_ACK_SIZE] = {
> > + 0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> > + int err;
>
> Reverse christmas tree ordering for the local variables please.
See below.
> > +static int pn532_uart_rx_is_frame(struct sk_buff *skb)
> > +{
> > + int i;
> > + u16 frame_len;
> > + struct pn533_std_frame *std;
> > + struct pn533_ext_frame *ext;
>
> Likewise.
Ok, I will do a v8 soon with these changes.
^ permalink raw reply
* Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
From: Tiwei Bie @ 2019-09-17 10:58 UTC (permalink / raw)
To: Jason Wang
Cc: mst, alex.williamson, maxime.coquelin, linux-kernel, kvm,
virtualization, netdev, dan.daly, cunming.liang, zhihong.wang,
lingshan.zhu
In-Reply-To: <993841ed-942e-c90b-8016-8e7dc76bf13a@redhat.com>
On Tue, Sep 17, 2019 at 11:32:03AM +0800, Jason Wang wrote:
> On 2019/9/17 上午9:02, Tiwei Bie wrote:
> > This RFC is to demonstrate below ideas,
> >
> > a) Build vhost-mdev on top of the same abstraction defined in
> > the virtio-mdev series [1];
> >
> > b) Introduce /dev/vhost-mdev to do vhost ioctls and support
> > setting mdev device as backend;
> >
> > Now the userspace API looks like this:
> >
> > - Userspace generates a compatible mdev device;
> >
> > - Userspace opens this mdev device with VFIO API (including
> > doing IOMMU programming for this mdev device with VFIO's
> > container/group based interface);
> >
> > - Userspace opens /dev/vhost-mdev and gets vhost fd;
> >
> > - Userspace uses vhost ioctls to setup vhost (userspace should
> > do VHOST_MDEV_SET_BACKEND ioctl with VFIO group fd and device
> > fd first before doing other vhost ioctls);
> >
> > Only compile test has been done for this series for now.
>
>
> Have a hard thought on the architecture:
Thanks a lot! Do appreciate it!
>
> 1) Create a vhost char device and pass vfio mdev device fd to it as a
> backend and translate vhost-mdev ioctl to virtio mdev transport (e.g
> read/write). DMA was done through the VFIO DMA mapping on the container that
> is attached.
Yeah, that's what we are doing in this series.
>
> We have two more choices:
>
> 2) Use vfio-mdev but do not create vhost-mdev device, instead, just
> implement vhost ioctl on vfio_device_ops, and translate them into
> virtio-mdev transport or just pass ioctl to parent.
Yeah. Instead of introducing /dev/vhost-mdev char device, do
vhost ioctls on VFIO device fd directly. That's what we did
in RFC v3.
>
> 3) Don't use vfio-mdev, create a new vhost-mdev driver, during probe still
> try to add dev to vfio group and talk to parent with device specific ops
If my understanding is correct, this means we need to introduce
a new VFIO device driver to replace the existing vfio-mdev driver
in our case. Below is a quick draft just to show my understanding:
#include <linux/init.h>
#include <linux/module.h>
#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/vfio.h>
#include <linux/mdev.h>
#include "mdev_private.h"
/* XXX: we need a proper way to include below vhost header. */
#include "../../vhost/vhost.h"
static int vfio_vhost_mdev_open(void *device_data)
{
if (!try_module_get(THIS_MODULE))
return -ENODEV;
/* ... */
vhost_dev_init(...);
return 0;
}
static void vfio_vhost_mdev_release(void *device_data)
{
/* ... */
module_put(THIS_MODULE);
}
static long vfio_vhost_mdev_unlocked_ioctl(void *device_data,
unsigned int cmd, unsigned long arg)
{
struct mdev_device *mdev = device_data;
struct mdev_parent *parent = mdev->parent;
/*
* Use vhost ioctls.
*
* We will have a different parent_ops design.
* And potentially, we can share the same parent_ops
* with virtio_mdev.
*/
switch (cmd) {
case VHOST_GET_FEATURES:
parent->ops->get_features(mdev, ...);
break;
/* ... */
}
return 0;
}
static ssize_t vfio_vhost_mdev_read(void *device_data, char __user *buf,
size_t count, loff_t *ppos)
{
/* ... */
return 0;
}
static ssize_t vfio_vhost_mdev_write(void *device_data, const char __user *buf,
size_t count, loff_t *ppos)
{
/* ... */
return 0;
}
static int vfio_vhost_mdev_mmap(void *device_data, struct vm_area_struct *vma)
{
/* ... */
return 0;
}
static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = {
.name = "vfio-vhost-mdev",
.open = vfio_vhost_mdev_open,
.release = vfio_vhost_mdev_release,
.ioctl = vfio_vhost_mdev_unlocked_ioctl,
.read = vfio_vhost_mdev_read,
.write = vfio_vhost_mdev_write,
.mmap = vfio_vhost_mdev_mmap,
};
static int vfio_vhost_mdev_probe(struct device *dev)
{
struct mdev_device *mdev = to_mdev_device(dev);
/* ... */
return vfio_add_group_dev(dev, &vfio_vhost_mdev_dev_ops, mdev);
}
static void vfio_vhost_mdev_remove(struct device *dev)
{
/* ... */
vfio_del_group_dev(dev);
}
static struct mdev_driver vfio_vhost_mdev_driver = {
.name = "vfio_vhost_mdev",
.probe = vfio_vhost_mdev_probe,
.remove = vfio_vhost_mdev_remove,
};
static int __init vfio_vhost_mdev_init(void)
{
return mdev_register_driver(&vfio_vhost_mdev_driver, THIS_MODULE);
}
module_init(vfio_vhost_mdev_init)
static void __exit vfio_vhost_mdev_exit(void)
{
mdev_unregister_driver(&vfio_vhost_mdev_driver);
}
module_exit(vfio_vhost_mdev_exit)
>
> So I have some questions:
>
> 1) Compared to method 2, what's the advantage of creating a new vhost char
> device? I guess it's for keep the API compatibility?
One benefit is that we can avoid doing vhost ioctls on
VFIO device fd.
>
> 2) For method 2, is there any easy way for user/admin to distinguish e.g
> ordinary vfio-mdev for vhost from ordinary vfio-mdev?
I think device-api could be a choice.
> I saw you introduce
> ops matching helper but it's not friendly to management.
The ops matching helper is just to check whether a given
vfio-device is based on a mdev device.
>
> 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that
> assumes the parameter comes from userspace, it prevents support kernel
> virtio drivers.
>
> 4) So comes the idea of method 3, since it register a new vhost-mdev driver,
> we can use device specific ops instead of VFIO ones, then we can have a
> common API between vDPA parent and vhost-mdev/virtio-mdev drivers.
As the above draft shows, this requires introducing a new
VFIO device driver. I think Alex's opinion matters here.
Thanks,
Tiwei
>
> What's your thoughts?
>
> Thanks
>
>
> >
> > RFCv3: https://patchwork.kernel.org/patch/11117785/
> >
> > [1] https://lkml.org/lkml/2019/9/10/135
> >
> > Tiwei Bie (3):
> > vfio: support getting vfio device from device fd
> > vfio: support checking vfio driver by device ops
> > vhost: introduce mdev based hardware backend
> >
> > drivers/vfio/mdev/vfio_mdev.c | 3 +-
> > drivers/vfio/vfio.c | 32 +++
> > drivers/vhost/Kconfig | 9 +
> > drivers/vhost/Makefile | 3 +
> > drivers/vhost/mdev.c | 462 +++++++++++++++++++++++++++++++
> > drivers/vhost/vhost.c | 39 ++-
> > drivers/vhost/vhost.h | 6 +
> > include/linux/vfio.h | 11 +
> > include/uapi/linux/vhost.h | 10 +
> > include/uapi/linux/vhost_types.h | 5 +
> > 10 files changed, 573 insertions(+), 7 deletions(-)
> > create mode 100644 drivers/vhost/mdev.c
> >
^ permalink raw reply
* Re: divide error in usbnet_update_max_qlen
From: Oliver Neukum @ 2019-09-17 11:22 UTC (permalink / raw)
To: syzbot, davem, andreyknvl, syzkaller-bugs, linux-kernel,
linux-usb, netdev
In-Reply-To: <000000000000b83b550592ab965b@google.com>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
Am Montag, den 16.09.2019, 06:29 -0700 schrieb syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=117659fa600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
> dashboard link: https://syzkaller.appspot.com/bug?extid=6102c120be558c885f04
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12107ba9600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=146014e6600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6102c120be558c885f04@syzkaller.appspotmail.com
#syz test: https://github.com/google/kasan.git f0df5c1b
[-- Attachment #2: 0001-usbnet-sanity-checking-of-packet-sizes.patch --]
[-- Type: text/x-patch, Size: 1073 bytes --]
From 57c2443b2a7678a6f7f6437f741f49f06a5104fb Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Tue, 17 Sep 2019 11:51:55 +0200
Subject: [PATCH] usbnet: sanity checking of packet sizes
Malicious devices can set this to zero and we divide by it.
Introduce sanity checking.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
drivers/net/usb/usbnet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 58952a79b05f..e44849499b89 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -339,6 +339,8 @@ void usbnet_update_max_qlen(struct usbnet *dev)
{
enum usb_device_speed speed = dev->udev->speed;
+ if (!dev->rx_urb_size || !dev->hard_mtu)
+ goto insanity;
switch (speed) {
case USB_SPEED_HIGH:
dev->rx_qlen = MAX_QUEUE_MEMORY / dev->rx_urb_size;
@@ -355,6 +357,7 @@ void usbnet_update_max_qlen(struct usbnet *dev)
dev->tx_qlen = 5 * MAX_QUEUE_MEMORY / dev->hard_mtu;
break;
default:
+insanity:
dev->rx_qlen = dev->tx_qlen = 4;
}
}
--
2.16.4
^ permalink raw reply related
* [RFC PATCH v2 0/6] Enable ptp_kvm for arm64
From: Jianyong Wu @ 2019-09-17 11:24 UTC (permalink / raw)
To: netdev, pbonzini, sean.j.christopherson, maz, richardcochran,
Mark.Rutland, Will.Deacon, suzuki.poulose
Cc: linux-kernel, Steve.Capper, Kaly.Xin, justin.he, jianyong.wu, nd,
linux-arm-kernel
kvm ptp targets to provide high precision time sync between guest
and host in virtualization environment. This patch enable kvm ptp
for arm64.
This patch set base on [1][2][3]
change log:
from v1 to v2:
(1) move arch-specific code from arch/ to driver/ptp/
(2) offer mechanism to inform userspace if ptp_kvm service is
available.
(3) separate ptp_kvm code for arm64 into hypervisor part and
guest part.
(4) add API to expose monotonic clock and counter value.
(5) refine code: remove no necessary part and reconsitution.
[1]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=125ea89e4a21e2fc5235410f966a996a1a7148bf
[2]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=464f5a1741e5959c3e4d2be1966ae0093b4dce06
[3]https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
commit/?h=kvm/hvc&id=6597490e005d0eeca8ed8c1c1d7b4318ee014681
Jianyong Wu (6):
Export psci_ops.conduit symbol as modules will use it.
reorganize ptp_kvm modules to make it arch-independent.
Timer: expose monotonic clock and counter value
arm64: Add hvc call service for ptp_kvm.
Enable ptp_kvm for arm64
kvm: add kvm ptp capability extension for arm64
drivers/firmware/psci/psci.c | 6 ++
drivers/ptp/Kconfig | 2 +-
drivers/ptp/Makefile | 1 +
drivers/ptp/{ptp_kvm.c => kvm_ptp.c} | 77 ++++++------------------
drivers/ptp/ptp_kvm_arm64.c | 82 ++++++++++++++++++++++++++
drivers/ptp/ptp_kvm_x86.c | 87 ++++++++++++++++++++++++++++
include/asm-generic/ptp_kvm.h | 12 ++++
include/linux/arm-smccc.h | 14 ++++-
include/linux/psci.h | 1 +
include/linux/timekeeping.h | 3 +
include/uapi/linux/kvm.h | 1 +
kernel/time/timekeeping.c | 13 +++++
virt/kvm/arm/arm.c | 1 +
virt/kvm/arm/psci.c | 17 ++++++
14 files changed, 256 insertions(+), 61 deletions(-)
rename drivers/ptp/{ptp_kvm.c => kvm_ptp.c} (63%)
create mode 100644 drivers/ptp/ptp_kvm_arm64.c
create mode 100644 drivers/ptp/ptp_kvm_x86.c
create mode 100644 include/asm-generic/ptp_kvm.h
--
2.17.1
^ permalink raw reply
* [PATCH 3/6] Timer: expose monotonic clock and counter value
From: Jianyong Wu @ 2019-09-17 11:24 UTC (permalink / raw)
To: netdev, pbonzini, sean.j.christopherson, maz, richardcochran,
Mark.Rutland, Will.Deacon, suzuki.poulose
Cc: linux-kernel, Steve.Capper, Kaly.Xin, justin.he, jianyong.wu, nd,
linux-arm-kernel
In-Reply-To: <20190917112430.45680-1-jianyong.wu@arm.com>
A number of PTP drivers (such as ptp-kvm) are assuming what the
current clock source is, which could lead to interesting effects on
systems where the clocksource can change depending on external events.
For this purpose, add a new API that retrives both the current
monotonic clock as well as its counter value.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
include/linux/timekeeping.h | 3 +++
kernel/time/timekeeping.c | 13 +++++++++++++
2 files changed, 16 insertions(+)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index a8ab0f143ac4..a5389adaa8bc 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -247,6 +247,9 @@ extern int get_device_system_crosststamp(
struct system_time_snapshot *history,
struct system_device_crosststamp *xtstamp);
+/* Obtain current monotonic clock and its counter value */
+extern void get_current_counterval(struct system_counterval_t *sc);
+
/*
* Simultaneously snapshot realtime and monotonic raw clocks
*/
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 44b726bab4bd..07a0969625b1 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1098,6 +1098,19 @@ static bool cycle_between(u64 before, u64 test, u64 after)
return false;
}
+/**
+ * get_current_counterval - Snapshot the current clocksource and counter value
+ * @sc: Pointer to a struct containing the current clocksource and its value
+ */
+void get_current_counterval(struct system_counterval_t *sc)
+{
+ struct timekeeper *tk = &tk_core.timekeeper;
+
+ sc->cs = READ_ONCE(tk->tkr_mono.clock);
+ sc->cycles = sc->cs->read(sc->cs);
+}
+EXPORT_SYMBOL_GPL(get_current_counterval);
+
/**
* get_device_system_crosststamp - Synchronously capture system/device timestamp
* @get_time_fn: Callback to get simultaneous device time and
--
2.17.1
^ permalink raw reply related
* [RFC PATCH v2 4/6] arm64: Add hvc call service for ptp_kvm.
From: Jianyong Wu @ 2019-09-17 11:24 UTC (permalink / raw)
To: netdev, pbonzini, sean.j.christopherson, maz, richardcochran,
Mark.Rutland, Will.Deacon, suzuki.poulose
Cc: linux-kernel, Steve.Capper, Kaly.Xin, justin.he, jianyong.wu, nd,
linux-arm-kernel
In-Reply-To: <20190917112430.45680-1-jianyong.wu@arm.com>
This patch is the base of ptp_kvm for arm64.
ptp_kvm modules will call hvc to get this service.
The service offers real time and counter cycle of host for guest.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
include/linux/arm-smccc.h | 12 ++++++++++++
virt/kvm/arm/psci.c | 17 +++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index a6e4d3e3d10a..bc0cdad10f35 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -94,6 +94,7 @@
/* KVM "vendor specific" services */
#define ARM_SMCCC_KVM_FUNC_FEATURES 0
+#define ARM_SMCCC_KVM_PTP 1
#define ARM_SMCCC_KVM_FUNC_FEATURES_2 127
#define ARM_SMCCC_KVM_NUM_FUNCS 128
@@ -103,6 +104,17 @@
ARM_SMCCC_OWNER_VENDOR_HYP, \
ARM_SMCCC_KVM_FUNC_FEATURES)
+/*
+ * This ID used for virtual ptp kvm clock and it will pass second value
+ * and nanosecond value of host real time and system counter by vcpu
+ * register to guest.
+ */
+#define ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_VENDOR_HYP, \
+ ARM_SMCCC_KVM_PTP)
+
#ifndef __ASSEMBLY__
#include <linux/linkage.h>
diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
index 0debf49bf259..2c5d53817a28 100644
--- a/virt/kvm/arm/psci.c
+++ b/virt/kvm/arm/psci.c
@@ -392,6 +392,8 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
u32 func_id = smccc_get_function(vcpu);
u32 val[4] = {};
u32 option;
+ struct timespec *ts;
+ struct system_counterval_t sc;
val[0] = SMCCC_RET_NOT_SUPPORTED;
@@ -431,6 +433,21 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID:
val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES);
break;
+ /*
+ * This will used for virtual ptp kvm clock. three
+ * values will be passed back.
+ * reg0 stores seconds of host real time;
+ * reg1 stores nanoseconds of host real time;
+ * reg2 stores system counter cycle value.
+ */
+ case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
+ getnstimeofday(ts);
+ get_current_counterval(&sc);
+ val[0] = ts->tv_sec;
+ val[1] = ts->tv_nsec;
+ val[2] = sc.cycles;
+ val[3] = 0;
+ break;
default:
return kvm_psci_call(vcpu);
}
--
2.17.1
^ permalink raw reply related
* [RFC PATCH V2 5/6] Enable ptp_kvm for arm64
From: Jianyong Wu @ 2019-09-17 11:24 UTC (permalink / raw)
To: netdev, pbonzini, sean.j.christopherson, maz, richardcochran,
Mark.Rutland, Will.Deacon, suzuki.poulose
Cc: linux-kernel, Steve.Capper, Kaly.Xin, justin.he, jianyong.wu, nd,
linux-arm-kernel
In-Reply-To: <20190917112430.45680-1-jianyong.wu@arm.com>
Currently in arm64 virtualization environment, there is no mechanism to
keep time sync between guest and host. Time in guest will drift compared
with host after boot up as they may both use third party time sources
to correct their time respectively. The time deviation will be in order
of milliseconds but some scenarios ask for higher time precision, like
in cloud envirenment, we want all the VMs running in the host aquire the
same level accuracy from host clock.
Use of kvm ptp clock, which choose the host clock source clock as a
reference clock to sync time clock between guest and host has been adopted
by x86 which makes the time sync order from milliseconds to nanoseconds.
This patch enable kvm ptp on arm64 and we get the similar clock drift as
found with x86 with kvm ptp.
Test result comparison between with kvm ptp and without it in arm64 are
as follows. This test derived from the result of command 'chronyc
sources'. we should take more cure of the last sample column which shows
the offset between the local clock and the source at the last measurement.
no kvm ptp in guest:
MS Name/IP address Stratum Poll Reach LastRx Last sample
========================================================================
^* dns1.synet.edu.cn 2 6 377 13 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 21 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 29 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 37 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 45 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 53 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 61 +1040us[+1581us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 4 -130us[ +796us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 12 -130us[ +796us] +/- 21ms
^* dns1.synet.edu.cn 2 6 377 20 -130us[ +796us] +/- 21ms
in host:
MS Name/IP address Stratum Poll Reach LastRx Last sample
========================================================================
^* 120.25.115.20 2 7 377 72 -470us[ -603us] +/- 18ms
^* 120.25.115.20 2 7 377 92 -470us[ -603us] +/- 18ms
^* 120.25.115.20 2 7 377 112 -470us[ -603us] +/- 18ms
^* 120.25.115.20 2 7 377 2 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 22 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 43 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 63 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 83 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 103 +872ns[-6808ns] +/- 17ms
^* 120.25.115.20 2 7 377 123 +872ns[-6808ns] +/- 17ms
The dns1.synet.edu.cn is the network reference clock for guest and
120.25.115.20 is the network reference clock for host. we can't get the
clock error between guest and host directly, but a roughly estimated value
will be in order of hundreds of us to ms.
with kvm ptp in guest:
chrony has been disabled in host to remove the disturb by network clock.
MS Name/IP address Stratum Poll Reach LastRx Last sample
========================================================================
* PHC0 0 3 377 8 -7ns[ +1ns] +/- 3ns
* PHC0 0 3 377 8 +1ns[ +16ns] +/- 3ns
* PHC0 0 3 377 6 -4ns[ -0ns] +/- 6ns
* PHC0 0 3 377 6 -8ns[ -12ns] +/- 5ns
* PHC0 0 3 377 5 +2ns[ +4ns] +/- 4ns
* PHC0 0 3 377 13 +2ns[ +4ns] +/- 4ns
* PHC0 0 3 377 12 -4ns[ -6ns] +/- 4ns
* PHC0 0 3 377 11 -8ns[ -11ns] +/- 6ns
* PHC0 0 3 377 10 -14ns[ -20ns] +/- 4ns
* PHC0 0 3 377 8 +4ns[ +5ns] +/- 4ns
The PHC0 is the ptp clock which choose the host clock as its source
clock. So we can be sure to say that the clock error between host and guest
is in order of ns.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
---
drivers/ptp/Kconfig | 2 +-
drivers/ptp/kvm_ptp.c | 2 +-
drivers/ptp/ptp_kvm_arm64.c | 82 +++++++++++++++++++++++++++++++++++++
3 files changed, 84 insertions(+), 2 deletions(-)
create mode 100644 drivers/ptp/ptp_kvm_arm64.c
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index 9b8fee5178e8..e032fafdafa7 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -110,7 +110,7 @@ config PTP_1588_CLOCK_PCH
config PTP_1588_CLOCK_KVM
tristate "KVM virtual PTP clock"
depends on PTP_1588_CLOCK
- depends on KVM_GUEST && X86
+ depends on KVM_GUEST && X86 || ARM64
default y
help
This driver adds support for using kvm infrastructure as a PTP
diff --git a/drivers/ptp/kvm_ptp.c b/drivers/ptp/kvm_ptp.c
index d8f215186904..c0b445fa6144 100644
--- a/drivers/ptp/kvm_ptp.c
+++ b/drivers/ptp/kvm_ptp.c
@@ -138,7 +138,7 @@ static int __init ptp_kvm_init(void)
int ret;
ret = kvm_arch_ptp_init();
- if (!ret)
+ if (ret)
return -EOPNOTSUPP;
kvm_ptp_clock.caps = ptp_kvm_caps;
diff --git a/drivers/ptp/ptp_kvm_arm64.c b/drivers/ptp/ptp_kvm_arm64.c
new file mode 100644
index 000000000000..630144186c08
--- /dev/null
+++ b/drivers/ptp/ptp_kvm_arm64.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Virtual PTP 1588 clock for use with KVM guests
+ * Copyright (C) 2019 ARM Ltd.
+ * All Rights Reserved
+ */
+
+#include <linux/kernel.h>
+#include <linux/err.h>
+#include <asm/hypervisor.h>
+#include <linux/module.h>
+#include <linux/psci.h>
+#include <linux/arm-smccc.h>
+#include <linux/timecounter.h>
+#include <linux/sched/clock.h>
+#include <asm/arch_timer.h>
+
+struct system_counterval_t ptp_sc;
+
+/*
+ * as trap call cause delay, this function will return the delay in nanosecond
+ */
+static u64 arm_smccc_1_1_invoke_delay(u32 id, struct arm_smccc_res *res)
+{
+ u64 t1, t2;
+
+ t1 = sched_clock();
+ arm_smccc_1_1_invoke(id, res);
+ t2 = sched_clock();
+ t2 -= t1;
+
+ return t2;
+}
+
+int kvm_arch_ptp_init(void)
+{
+ if (!kvm_arm_hyp_service_available(
+ ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID)) {
+ return -EOPNOTSUPP;
+ }
+ get_current_counterval(&ptp_sc);
+
+ return 0;
+}
+
+int kvm_arch_ptp_get_clock_generic(struct timespec64 *ts,
+ struct arm_smccc_res *hvc_res)
+{
+ u64 ns;
+
+ ns = arm_smccc_1_1_invoke_delay(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
+ hvc_res);
+ if ((long)(hvc_res->a0) < 0)
+ return -EOPNOTSUPP;
+
+ ts->tv_sec = hvc_res->a0;
+ ts->tv_nsec = hvc_res->a1;
+ timespec64_add_ns(ts, ns);
+
+ return 0;
+}
+
+int kvm_arch_ptp_get_clock(struct timespec64 *ts)
+{
+ struct arm_smccc_res hvc_res;
+
+ kvm_arch_ptp_get_clock_generic(ts, &hvc_res);
+
+ return 0;
+}
+
+int kvm_arch_ptp_get_clock_fn(long *cycle, struct timespec64 *ts,
+ struct clocksource **cs)
+{
+ struct arm_smccc_res hvc_res;
+
+ kvm_arch_ptp_get_clock_generic(ts, &hvc_res);
+ *cycle = hvc_res.a2;
+ *cs = ptp_sc.cs;
+
+ return 0;
+}
--
2.17.1
^ permalink raw reply related
* [PATCH 6/6] kvm: add kvm ptp capability extension for arm64
From: Jianyong Wu @ 2019-09-17 11:24 UTC (permalink / raw)
To: netdev, pbonzini, sean.j.christopherson, maz, richardcochran,
Mark.Rutland, Will.Deacon, suzuki.poulose
Cc: linux-kernel, Steve.Capper, Kaly.Xin, justin.he, jianyong.wu, nd,
linux-arm-kernel
In-Reply-To: <20190917112430.45680-1-jianyong.wu@arm.com>
Let userspace check if there is kvm ptp service in host.
before VMs migrate to a another host, VMM may check if this
cap is available to determine the migration behaviour.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Suggested-by: Marc Zyngier <maz@kernel.org>
---
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2fe12b40d503..a0bff6002bd9 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -993,6 +993,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_ARM_SVE 170
#define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
#define KVM_CAP_ARM_PTRAUTH_GENERIC 172
+#define KVM_CAP_ARM_KVM_PTP 173
#ifdef KVM_CAP_IRQ_ROUTING
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index bd5c55916d0d..80999985160b 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -201,6 +201,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_MP_STATE:
case KVM_CAP_IMMEDIATE_EXIT:
case KVM_CAP_VCPU_EVENTS:
+ case KVM_CAP_ARM_KVM_PTP:
r = 1;
break;
case KVM_CAP_ARM_SET_DEVICE_ADDR:
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox