Re: [RFC v5 0/5] virtio: support packed ring

2018-05-24 Thread Tiwei Bie 
On Fri, May 25, 2018 at 10:31:26AM +0800, Jason Wang wrote:
> On 2018年05月22日 16:16, Tiwei Bie wrote:
> > Hello everyone,
> > 
> > This RFC implements packed ring support in virtio driver.
> > 
> > Some simple functional tests have been done with Jason's
> > packed ring implementation in vhost (RFC v4):
> > 
> > https://lkml.org/lkml/2018/5/16/501
> > 
> > Both of ping and netperf worked as expected w/ EVENT_IDX
> > disabled. Ping worked as expected w/ EVENT_IDX enabled,
> > but netperf didn't (A hack has been added in the driver
> > to make netperf test pass in this case. The hack can be
> > found by `grep -rw XXX` in the code).
> 
> Looks like this is because a bug in vhost which wrongly track signalled_used
> and may miss an interrupt. After fixing that, both side works like a charm.
> 
> I'm testing vIOMMU and zerocopy, and will post a new version shortly. (Hope
> it would be the last RFC version).

Great to know that. Thanks a lot! :)

Best regards,
Tiwei Bie
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC v5 0/5] virtio: support packed ring

2018-05-24 Thread Jason Wang 



On 2018年05月22日 16:16, Tiwei Bie wrote:

Hello everyone,

This RFC implements packed ring support in virtio driver.

Some simple functional tests have been done with Jason's
packed ring implementation in vhost (RFC v4):

https://lkml.org/lkml/2018/5/16/501

Both of ping and netperf worked as expected w/ EVENT_IDX
disabled. Ping worked as expected w/ EVENT_IDX enabled,
but netperf didn't (A hack has been added in the driver
to make netperf test pass in this case. The hack can be
found by `grep -rw XXX` in the code).


Looks like this is because a bug in vhost which wrongly track 
signalled_used and may miss an interrupt. After fixing that, both side 
works like a charm.


I'm testing vIOMMU and zerocopy, and will post a new version shortly. 
(Hope it would be the last RFC version).


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

Re: [RFC V4 PATCH 8/8] vhost: event suppression for packed ring

2018-05-24 Thread Jason Wang 



On 2018年05月16日 20:32, Jason Wang wrote:

+static bool vhost_notify_packed(struct vhost_dev *dev,
+   struct vhost_virtqueue *vq)
+{
+   __virtio16 event_off_wrap, event_flags;
+   __u16 old, new, off_wrap;
+   bool v;
+
+   /* Flush out used descriptors updates. This is paired
+* with the barrier that the Guest executes when enabling
+* interrupts.
+*/
+   smp_mb();
+
+   if (vhost_get_avail(vq, event_flags,
+  >driver_event->flags) < 0) {
+   vq_err(vq, "Failed to get driver desc_event_flags");
+   return true;
+   }
+
+   if (event_flags == cpu_to_vhost16(vq, RING_EVENT_FLAGS_DISABLE))
+   return false;
+   else if (event_flags == cpu_to_vhost16(vq, RING_EVENT_FLAGS_ENABLE))
+   return true;
+
+   /* Read desc event flags before event_off and event_wrap */
+   smp_rmb();
+
+   if (vhost_get_avail(vq, event_off_wrap,
+   >driver_event->off_warp) < 0) {
+   vq_err(vq, "Failed to get driver desc_event_off/wrap");
+   return true;
+   }
+
+   off_wrap = vhost16_to_cpu(vq, event_off_wrap);
+
+   old = vq->signalled_used;
+   v = vq->signalled_used_valid;
+   new = vq->signalled_used = vq->last_used_idx;
+   vq->signalled_used_valid = true;


We should move those idx tracking before checking event_flags. Otherwise 
we may lose interrupts because of a wrong signalled_used value.


Thanks


+
+   if (unlikely(!v))
+   return true;
+
+   return vhost_vring_packed_need_event(vq, off_wrap, new, old);
+}


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

Re: [PATCH net] vhost: synchronize IOTLB message with dev cleanup

2018-05-24 Thread David Miller 
From: Jason Wang 
Date: Tue, 22 May 2018 19:58:57 +0800

> DaeRyong Jeong reports a race between vhost_dev_cleanup() and
> vhost_process_iotlb_msg():
> 
> Thread interleaving:
> CPU0 (vhost_process_iotlb_msg)CPU1 (vhost_dev_cleanup)
> (In the case of both VHOST_IOTLB_UPDATE and
> VHOST_IOTLB_INVALIDATE)
> = =
>   vhost_umem_clean(dev->iotlb);
> if (!dev->iotlb) {
>   ret = -EFAULT;
>   break;
> }
>   dev->iotlb = NULL;
> 
> The reason is we don't synchronize between them, fixing by protecting
> vhost_process_iotlb_msg() with dev mutex.
> 
> Reported-by: DaeRyong Jeong 
> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
> Signed-off-by: Jason Wang 

Applied and queued up for -stable.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH net] vhost: synchronize IOTLB message with dev cleanup

2018-05-24 Thread Michael S. Tsirkin 
On Tue, May 22, 2018 at 07:58:57PM +0800, Jason Wang wrote:
> DaeRyong Jeong reports a race between vhost_dev_cleanup() and
> vhost_process_iotlb_msg():
> 
> Thread interleaving:
> CPU0 (vhost_process_iotlb_msg)CPU1 (vhost_dev_cleanup)
> (In the case of both VHOST_IOTLB_UPDATE and
> VHOST_IOTLB_INVALIDATE)
> = =
>   vhost_umem_clean(dev->iotlb);
> if (!dev->iotlb) {
>   ret = -EFAULT;
>   break;
> }
>   dev->iotlb = NULL;
> 
> The reason is we don't synchronize between them, fixing by protecting
> vhost_process_iotlb_msg() with dev mutex.
> 
> Reported-by: DaeRyong Jeong 
> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
> Signed-off-by: Jason Wang 

We should think of a way to have a per-vq lock here, but for now:

Acked-by: Michael S. Tsirkin 

> ---
>  drivers/vhost/vhost.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index f3bd8e9..f0be5f3 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -981,6 +981,7 @@ static int vhost_process_iotlb_msg(struct vhost_dev *dev,
>  {
>   int ret = 0;
>  
> + mutex_lock(>mutex);
>   vhost_dev_lock_vqs(dev);
>   switch (msg->type) {
>   case VHOST_IOTLB_UPDATE:
> @@ -1016,6 +1017,8 @@ static int vhost_process_iotlb_msg(struct vhost_dev 
> *dev,
>   }
>  
>   vhost_dev_unlock_vqs(dev);
> + mutex_unlock(>mutex);
> +
>   return ret;
>  }
>  ssize_t vhost_chr_write_iter(struct vhost_dev *dev,
> -- 
> 2.7.4
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

2018-05-24 Thread Thomas Garnier via Virtualization 
On Thu, May 24, 2018 at 1:16 PM Steven Rostedt  wrote:

> On Thu, 24 May 2018 13:40:24 +0200
> Petr Mladek  wrote:

> > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> > > When using -fPIE/PIC with function tracing, the compiler generates a
> > > call through the GOT (call *__fentry__@GOTPCREL). This instruction
> > > takes 6 bytes instead of 5 on the usual relative call.
> > >
> > > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte
nop
> > > so ftrace can handle the previous 5-bytes as before.
> > >
> > > Position Independent Executable (PIE) support will allow to extended
the
> > > KASLR randomization range below the -2G memory limit.
> > >
> > > Signed-off-by: Thomas Garnier 
> > > ---
> > >  arch/x86/include/asm/ftrace.h   |  6 +++--
> > >  arch/x86/include/asm/sections.h |  4 
> > >  arch/x86/kernel/ftrace.c| 42
+++--
> > >  3 files changed, 48 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/x86/include/asm/ftrace.h
b/arch/x86/include/asm/ftrace.h
> > > index c18ed65287d5..8f2decce38d8 100644
> > > --- a/arch/x86/include/asm/ftrace.h
> > > +++ b/arch/x86/include/asm/ftrace.h
> > > @@ -25,9 +25,11 @@ extern void __fentry__(void);
> > >  static inline unsigned long ftrace_call_adjust(unsigned long addr)
> > >  {
> > > /*
> > > -* addr is the address of the mcount call instruction.
> > > -* recordmcount does the necessary offset calculation.
> > > +* addr is the address of the mcount call instruction. PIE has
always a
> > > +* byte added to the start of the function.
> > >  */
> > > +   if (IS_ENABLED(CONFIG_X86_PIE))
> > > +   addr -= 1;
> >
> > This seems to modify the address even for modules that are _not_
compiled with
> > PIE, see below.

> Can one load a module not compiled for PIE in a kernel with PIE?

> >
> > > return addr;
> > >  }
> > >
> > > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > > index 01ebcb6f263e..73b3c30cb7a3 100644
> > > --- a/arch/x86/kernel/ftrace.c
> > > +++ b/arch/x86/kernel/ftrace.c
> > > @@ -135,6 +135,44 @@ ftrace_modify_code_direct(unsigned long ip,
unsigned const char *old_code,
> > > return 0;
> > >  }
> > >
> > > +/* Bytes before call GOT offset */
> > > +const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
> > > +
> > > +static int
> > > +ftrace_modify_initial_code(unsigned long ip, unsigned const char
*old_code,
> > > +  unsigned const char *new_code)
> > > +{
> > > +   unsigned char replaced[MCOUNT_INSN_SIZE + 1];
> > > +
> > > +   ftrace_expected = old_code;
> > > +
> > > +   /*
> > > +* If PIE is not enabled or no GOT call was found, default to the
> > > +* original approach to code modification.
> > > +*/
> > > +   if (!IS_ENABLED(CONFIG_X86_PIE) ||
> > > +   probe_kernel_read(replaced, (void *)ip, sizeof(replaced)) ||
> > > +   memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
> > > +   return ftrace_modify_code_direct(ip, old_code, new_code);
> >
> > And this looks like an attempt to handle modules compiled without
> > PIE. Does it works with the right ip in that case?

> I'm guessing the || is for the "or no GOT call was found", but it
> doesn't explain why no GOT would be found.

Yes, maybe I could have made it work by using text_ip_addr earlier.


> >
> > I wonder if a better solution would be to update
> > scripts/recordmcount.c to store the incremented location into the
module.

I will look into it.


> If recordmcount.c can handle this, then I think that's the preferred
> approach. Thanks!

> -- Steve

> >
> > IMPORTANT: I have only vague picture about how this all works. It is
> > possible that I am completely wrong. The code might be correct,
> > especially if you tested this situation.
> >
> > Best Regards,
> > Petr



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

Re: [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

2018-05-24 Thread Steven Rostedt 
On Thu, 24 May 2018 13:40:24 +0200
Petr Mladek  wrote:

> On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> > When using -fPIE/PIC with function tracing, the compiler generates a
> > call through the GOT (call *__fentry__@GOTPCREL). This instruction
> > takes 6 bytes instead of 5 on the usual relative call.
> > 
> > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
> > so ftrace can handle the previous 5-bytes as before.
> > 
> > Position Independent Executable (PIE) support will allow to extended the
> > KASLR randomization range below the -2G memory limit.
> > 
> > Signed-off-by: Thomas Garnier 
> > ---
> >  arch/x86/include/asm/ftrace.h   |  6 +++--
> >  arch/x86/include/asm/sections.h |  4 
> >  arch/x86/kernel/ftrace.c| 42 +++--
> >  3 files changed, 48 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> > index c18ed65287d5..8f2decce38d8 100644
> > --- a/arch/x86/include/asm/ftrace.h
> > +++ b/arch/x86/include/asm/ftrace.h
> > @@ -25,9 +25,11 @@ extern void __fentry__(void);
> >  static inline unsigned long ftrace_call_adjust(unsigned long addr)
> >  {
> > /*
> > -* addr is the address of the mcount call instruction.
> > -* recordmcount does the necessary offset calculation.
> > +* addr is the address of the mcount call instruction. PIE has always a
> > +* byte added to the start of the function.
> >  */
> > +   if (IS_ENABLED(CONFIG_X86_PIE))
> > +   addr -= 1;  
> 
> This seems to modify the address even for modules that are _not_ compiled with
> PIE, see below.

Can one load a module not compiled for PIE in a kernel with PIE?

> 
> > return addr;
> >  }
> >  
> > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > index 01ebcb6f263e..73b3c30cb7a3 100644
> > --- a/arch/x86/kernel/ftrace.c
> > +++ b/arch/x86/kernel/ftrace.c
> > @@ -135,6 +135,44 @@ ftrace_modify_code_direct(unsigned long ip, unsigned 
> > const char *old_code,
> > return 0;
> >  }
> >  
> > +/* Bytes before call GOT offset */
> > +const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
> > +
> > +static int
> > +ftrace_modify_initial_code(unsigned long ip, unsigned const char *old_code,
> > +  unsigned const char *new_code)
> > +{
> > +   unsigned char replaced[MCOUNT_INSN_SIZE + 1];
> > +
> > +   ftrace_expected = old_code;
> > +
> > +   /*
> > +* If PIE is not enabled or no GOT call was found, default to the
> > +* original approach to code modification.
> > +*/
> > +   if (!IS_ENABLED(CONFIG_X86_PIE) ||
> > +   probe_kernel_read(replaced, (void *)ip, sizeof(replaced)) ||
> > +   memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
> > +   return ftrace_modify_code_direct(ip, old_code, new_code);  
> 
> And this looks like an attempt to handle modules compiled without
> PIE. Does it works with the right ip in that case?

I'm guessing the || is for the "or no GOT call was found", but it
doesn't explain why no GOT would be found.

> 
> I wonder if a better solution would be to update
> scripts/recordmcount.c to store the incremented location into the module.

If recordmcount.c can handle this, then I think that's the preferred
approach. Thanks!

-- Steve

> 
> IMPORTANT: I have only vague picture about how this all works. It is
> possible that I am completely wrong. The code might be correct,
> especially if you tested this situation.
> 
> Best Regards,
> Petr

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

Re: [PATCH] block drivers/block: Use octal not symbolic permissions

2018-05-24 Thread Jens Axboe 
On 5/24/18 7:01 AM, Joe Perches wrote:
> On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote:
>> On 5/23/18 4:35 PM, Joe Perches wrote:
>>> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
 On 5/23/18 2:05 PM, Joe Perches wrote:
> Convert the S_ symbolic permissions to their octal equivalents as
> using octal and not symbolic permissions is preferred by many as more
> readable.
>
> see: https://lkml.org/lkml/2016/8/2/1945
>
> Done with automated conversion via:
> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> 
>
> Miscellanea:
>
> o Wrapped modified multi-line calls to a single line where appropriate
> o Realign modified multi-line calls to open parenthesis

 Honestly, I see this as pretty needless churn.
>>>
>>> btw:
>>>
>>> There is currently a mixture of symbolic and octal
>>> permissions uses in block and drivers/block
>>>
>>> ie: 94 octal and 146 symbolic uses.
>>>
>>> If this is applied, all would become octal.
>>
>> That does help justify the change. My main worry here is creating
>> unnecessary conflicts, which is always annoying. But it's even more
>> annoying when the change creating the conflict isn't really that
>> important at all. Case in point, the patch doesn't apply to the
>> for-4.18/block branch that it should go into...
> 
> Done against most recent -next as it's basically impossible
> to do anything against multiple private trees.
> 
> Also, the script that generated the patch is in the changelog
> so it's simple to rerun.

Alright, applied, thanks.

-- 
Jens Axboe

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

Re: [PATCH net] vhost: synchronize IOTLB message with dev cleanup

2018-05-24 Thread David Miller 
From: Jason Wang 
Date: Tue, 22 May 2018 19:58:57 +0800

> DaeRyong Jeong reports a race between vhost_dev_cleanup() and
> vhost_process_iotlb_msg():
> 
> Thread interleaving:
> CPU0 (vhost_process_iotlb_msg)CPU1 (vhost_dev_cleanup)
> (In the case of both VHOST_IOTLB_UPDATE and
> VHOST_IOTLB_INVALIDATE)
> = =
>   vhost_umem_clean(dev->iotlb);
> if (!dev->iotlb) {
>   ret = -EFAULT;
>   break;
> }
>   dev->iotlb = NULL;
> 
> The reason is we don't synchronize between them, fixing by protecting
> vhost_process_iotlb_msg() with dev mutex.
> 
> Reported-by: DaeRyong Jeong 
> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
> Signed-off-by: Jason Wang 

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

[PATCH net-next v12 3/5] net: Introduce net_failover driver

2018-05-24 Thread Sridhar Samudrala 
The net_failover driver provides an automated failover mechanism via APIs
to create and destroy a failover master netdev and manages a primary and
standby slave netdevs that get registered via the generic failover
infrastructure.

The failover netdev acts a master device and controls 2 slave devices. The
original paravirtual interface gets registered as 'standby' slave netdev and
a passthru/vf device with the same MAC gets registered as 'primary' slave
netdev. Both 'standby' and 'failover' netdevs are associated with the same
'pci' device. The user accesses the network interface via 'failover' netdev.
The 'failover' netdev chooses 'primary' netdev as default for transmits when
it is available with link up and running.

This can be used by paravirtual drivers to enable an alternate low latency
datapath. It also enables hypervisor controlled live migration of a VM with
direct attached VF by failing over to the paravirtual datapath when the VF
is unplugged.

Signed-off-by: Sridhar Samudrala 
---
 Documentation/networking/net_failover.rst |  26 +
 MAINTAINERS   |   8 +
 drivers/net/Kconfig   |  12 +
 drivers/net/Makefile  |   1 +
 drivers/net/net_failover.c| 836 ++
 include/net/net_failover.h|  40 ++
 6 files changed, 923 insertions(+)
 create mode 100644 Documentation/networking/net_failover.rst
 create mode 100644 drivers/net/net_failover.c
 create mode 100644 include/net/net_failover.h

diff --git a/Documentation/networking/net_failover.rst 
b/Documentation/networking/net_failover.rst
new file mode 100644
index ..d4513ad31809
--- /dev/null
+++ b/Documentation/networking/net_failover.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+NET_FAILOVER
+
+
+Overview
+
+
+The net_failover driver provides an automated failover mechanism via APIs
+to create and destroy a failover master netdev and mananges a primary and
+standby slave netdevs that get registered via the generic failover
+infrastructrure.
+
+The failover netdev acts a master device and controls 2 slave devices. The
+original paravirtual interface is registered as 'standby' slave netdev and
+a passthru/vf device with the same MAC gets registered as 'primary' slave
+netdev. Both 'standby' and 'failover' netdevs are associated with the same
+'pci' device. The user accesses the network interface via 'failover' netdev.
+The 'failover' netdev chooses 'primary' netdev as default for transmits when
+it is available with link up and running.
+
+This can be used by paravirtual drivers to enable an alternate low latency
+datapath. It also enables hypervisor controlled live migration of a VM with
+direct attached VF by failing over to the paravirtual datapath when the VF
+is unplugged.
diff --git a/MAINTAINERS b/MAINTAINERS
index ee0ce10b2a8d..0cc6a5bb0b60 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9642,6 +9642,14 @@ S:   Maintained
 F: Documentation/hwmon/nct6775
 F: drivers/hwmon/nct6775.c
 
+NET_FAILOVER MODULE
+M: Sridhar Samudrala 
+L: net...@vger.kernel.org
+S: Supported
+F: driver/net/net_failover.c
+F: include/net/net_failover.h
+F: Documentation/networking/net_failover.rst
+
 NETEFFECT IWARP RNIC DRIVER (IW_NES)
 M: Faisal Latif 
 L: linux-r...@vger.kernel.org
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a029b27fd002..2cdaff90a9ec 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -510,4 +510,16 @@ config NETDEVSIM
  To compile this driver as a module, choose M here: the module
  will be called netdevsim.
 
+config NET_FAILOVER
+   tristate "Failover driver"
+   select FAILOVER
+   help
+ This provides an automated failover mechanism via APIs to create
+ and destroy a failover master netdev and manages a primary and
+ standby slave netdevs that get registered via the generic failover
+ infrastructure. This can be used by paravirtual drivers to enable
+ an alternate low latency datapath. It alsoenables live migration of
+ a VM with direct attached VF by failing over to the paravirtual
+ datapath when the VF is unplugged.
+
 endif # NETDEVICES
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 91e67e375dd4..21cde7e78621 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_FUJITSU_ES) += fjes/
 thunderbolt-net-y += thunderbolt.o
 obj-$(CONFIG_THUNDERBOLT_NET) += thunderbolt-net.o
 obj-$(CONFIG_NETDEVSIM) += netdevsim/
+obj-$(CONFIG_NET_FAILOVER) += net_failover.o
diff --git a/drivers/net/net_failover.c b/drivers/net/net_failover.c
new file mode 100644
index ..8b508e2cf29b
--- /dev/null
+++ b/drivers/net/net_failover.c
@@ -0,0 +1,836 @@
+// SPDX-License-Identifier: GPL-2.0
+/*

[PATCH net-next v12 1/5] net: Introduce generic failover module

2018-05-24 Thread Sridhar Samudrala 
The failover module provides a generic interface for paravirtual drivers
to register a netdev and a set of ops with a failover instance. The ops
are used as event handlers that get called to handle netdev register/
unregister/link change/name change events on slave pci ethernet devices
with the same mac address as the failover netdev.

This enables paravirtual drivers to use a VF as an accelerated low latency
datapath. It also allows migration of VMs with direct attached VFs by
failing over to the paravirtual datapath when the VF is unplugged.

Signed-off-by: Sridhar Samudrala 
---
 Documentation/networking/failover.rst |  18 ++
 MAINTAINERS   |   8 +
 include/linux/netdevice.h |  16 ++
 include/net/failover.h|  36 
 net/Kconfig   |  13 ++
 net/core/Makefile |   1 +
 net/core/failover.c   | 315 ++
 7 files changed, 407 insertions(+)
 create mode 100644 Documentation/networking/failover.rst
 create mode 100644 include/net/failover.h
 create mode 100644 net/core/failover.c

diff --git a/Documentation/networking/failover.rst 
b/Documentation/networking/failover.rst
new file mode 100644
index ..f0c8483cdbf5
--- /dev/null
+++ b/Documentation/networking/failover.rst
@@ -0,0 +1,18 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+FAILOVER
+
+
+Overview
+
+
+The failover module provides a generic interface for paravirtual drivers
+to register a netdev and a set of ops with a failover instance. The ops
+are used as event handlers that get called to handle netdev register/
+unregister/link change/name change events on slave pci ethernet devices
+with the same mac address as the failover netdev.
+
+This enables paravirtual drivers to use a VF as an accelerated low latency
+datapath. It also allows live migration of VMs with direct attached VFs by
+failing over to the paravirtual datapath when the VF is unplugged.
diff --git a/MAINTAINERS b/MAINTAINERS
index 032807a95558..ee0ce10b2a8d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5412,6 +5412,14 @@ S:   Maintained
 F: Documentation/hwmon/f71805f
 F: drivers/hwmon/f71805f.c
 
+FAILOVER MODULE
+M: Sridhar Samudrala 
+L: net...@vger.kernel.org
+S: Supported
+F: net/core/failover.c
+F: include/net/failover.h
+F: Documentation/networking/failover.rst
+
 FANOTIFY
 M: Jan Kara 
 R: Amir Goldstein 
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 03ed492c4e14..0f4ba52b641d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1421,6 +1421,8 @@ struct net_device_ops {
  * entity (i.e. the master device for bridged veth)
  * @IFF_MACSEC: device is a MACsec device
  * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
+ * @IFF_FAILOVER: device is a failover master device
+ * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
  */
 enum netdev_priv_flags {
IFF_802_1Q_VLAN = 1<<0,
@@ -1450,6 +1452,8 @@ enum netdev_priv_flags {
IFF_PHONY_HEADROOM  = 1<<24,
IFF_MACSEC  = 1<<25,
IFF_NO_RX_HANDLER   = 1<<26,
+   IFF_FAILOVER= 1<<27,
+   IFF_FAILOVER_SLAVE  = 1<<28,
 };
 
 #define IFF_802_1Q_VLANIFF_802_1Q_VLAN
@@ -1478,6 +1482,8 @@ enum netdev_priv_flags {
 #define IFF_RXFH_CONFIGUREDIFF_RXFH_CONFIGURED
 #define IFF_MACSEC IFF_MACSEC
 #define IFF_NO_RX_HANDLER  IFF_NO_RX_HANDLER
+#define IFF_FAILOVER   IFF_FAILOVER
+#define IFF_FAILOVER_SLAVE IFF_FAILOVER_SLAVE
 
 /**
  * struct net_device - The DEVICE structure.
@@ -4321,6 +4327,16 @@ static inline bool netif_is_rxfh_configured(const struct 
net_device *dev)
return dev->priv_flags & IFF_RXFH_CONFIGURED;
 }
 
+static inline bool netif_is_failover(const struct net_device *dev)
+{
+   return dev->priv_flags & IFF_FAILOVER;
+}
+
+static inline bool netif_is_failover_slave(const struct net_device *dev)
+{
+   return dev->priv_flags & IFF_FAILOVER_SLAVE;
+}
+
 /* This device needs to keep skb dst for qdisc enqueue or ndo_start_xmit() */
 static inline void netif_keep_dst(struct net_device *dev)
 {
diff --git a/include/net/failover.h b/include/net/failover.h
new file mode 100644
index ..bb15438f39c7
--- /dev/null
+++ b/include/net/failover.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, Intel Corporation. */
+
+#ifndef _FAILOVER_H
+#define _FAILOVER_H
+
+#include 
+
+struct failover_ops {
+   int (*slave_pre_register)(struct net_device *slave_dev,
+ struct net_device *failover_dev);
+   int (*slave_register)(struct

[PATCH net-next v12 4/5] virtio_net: Introduce VIRTIO_NET_F_STANDBY feature bit

2018-05-24 Thread Sridhar Samudrala 
This feature bit can be used by hypervisor to indicate virtio_net device to
act as a standby for another device with the same MAC address.

VIRTIO_NET_F_STANDBY is defined as bit 62 as it is a device feature bit.

Signed-off-by: Sridhar Samudrala 
---
 drivers/net/virtio_net.c| 2 +-
 include/uapi/linux/virtio_net.h | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f34794a76c4d..213fddc70fd0 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2999,7 +2999,7 @@ static struct virtio_device_id id_table[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
VIRTIO_NET_F_CTRL_MAC_ADDR, \
VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
-   VIRTIO_NET_F_SPEED_DUPLEX
+   VIRTIO_NET_F_SPEED_DUPLEX, VIRTIO_NET_F_STANDBY
 
 static unsigned int features[] = {
VIRTNET_FEATURES,
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index 5de6ed37695b..a3715a3224c1 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -57,6 +57,9 @@
 * Steering */
 #define VIRTIO_NET_F_CTRL_MAC_ADDR 23  /* Set MAC address */
 
+#define VIRTIO_NET_F_STANDBY 62/* Act as standby for another device
+* with the same MAC.
+*/
 #define VIRTIO_NET_F_SPEED_DUPLEX 63   /* Device set linkspeed and duplex */
 
 #ifndef VIRTIO_NET_NO_LEGACY
-- 
2.14.3

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

[PATCH net-next v12 2/5] netvsc: refactor notifier/event handling code to use the failover framework

2018-05-24 Thread Sridhar Samudrala 
Use the registration/notification framework supported by the generic
failover infrastructure.

Signed-off-by: Sridhar Samudrala 
---
 drivers/net/hyperv/Kconfig  |   1 +
 drivers/net/hyperv/hyperv_net.h |   2 +
 drivers/net/hyperv/netvsc_drv.c | 222 +++-
 3 files changed, 60 insertions(+), 165 deletions(-)

diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index 0765d5f61714..23a2d145813a 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -2,5 +2,6 @@ config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
depends on HYPERV
select UCS2_STRING
+   select FAILOVER
help
  Select this option to enable the Hyper-V virtual network driver.
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 1be34d2e3563..99d8e7398a5b 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -932,6 +932,8 @@ struct net_device_context {
u32 vf_alloc;
/* Serial number of the VF to team with */
u32 vf_serial;
+
+   struct failover *failover;
 };
 
 /* Per channel data */
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index da07ccdf84bf..62eb136c5e73 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hyperv_net.h"
 
@@ -1763,46 +1764,6 @@ static void netvsc_link_change(struct work_struct *w)
rtnl_unlock();
 }
 
-static struct net_device *get_netvsc_bymac(const u8 *mac)
-{
-   struct net_device *dev;
-
-   ASSERT_RTNL();
-
-   for_each_netdev(_net, dev) {
-   if (dev->netdev_ops != _ops)
-   continue;   /* not a netvsc device */
-
-   if (ether_addr_equal(mac, dev->perm_addr))
-   return dev;
-   }
-
-   return NULL;
-}
-
-static struct net_device *get_netvsc_byref(struct net_device *vf_netdev)
-{
-   struct net_device *dev;
-
-   ASSERT_RTNL();
-
-   for_each_netdev(_net, dev) {
-   struct net_device_context *net_device_ctx;
-
-   if (dev->netdev_ops != _ops)
-   continue;   /* not a netvsc device */
-
-   net_device_ctx = netdev_priv(dev);
-   if (!rtnl_dereference(net_device_ctx->nvdev))
-   continue;   /* device is removed */
-
-   if (rtnl_dereference(net_device_ctx->vf_netdev) == vf_netdev)
-   return dev; /* a match */
-   }
-
-   return NULL;
-}
-
 /* Called when VF is injecting data into network stack.
  * Change the associated network device from VF to netvsc.
  * note: already called with rcu_read_lock
@@ -1825,46 +1786,6 @@ static rx_handler_result_t netvsc_vf_handle_frame(struct 
sk_buff **pskb)
return RX_HANDLER_ANOTHER;
 }
 
-static int netvsc_vf_join(struct net_device *vf_netdev,
- struct net_device *ndev)
-{
-   struct net_device_context *ndev_ctx = netdev_priv(ndev);
-   int ret;
-
-   ret = netdev_rx_handler_register(vf_netdev,
-netvsc_vf_handle_frame, ndev);
-   if (ret != 0) {
-   netdev_err(vf_netdev,
-  "can not register netvsc VF receive handler (err = 
%d)\n",
-  ret);
-   goto rx_handler_failed;
-   }
-
-   ret = netdev_master_upper_dev_link(vf_netdev, ndev,
-  NULL, NULL, NULL);
-   if (ret != 0) {
-   netdev_err(vf_netdev,
-  "can not set master device %s (err = %d)\n",
-  ndev->name, ret);
-   goto upper_link_failed;
-   }
-
-   /* set slave flag before open to prevent IPv6 addrconf */
-   vf_netdev->flags |= IFF_SLAVE;
-
-   schedule_delayed_work(_ctx->vf_takeover, VF_TAKEOVER_INT);
-
-   call_netdevice_notifiers(NETDEV_JOIN, vf_netdev);
-
-   netdev_info(vf_netdev, "joined to %s\n", ndev->name);
-   return 0;
-
-upper_link_failed:
-   netdev_rx_handler_unregister(vf_netdev);
-rx_handler_failed:
-   return ret;
-}
-
 static void __netvsc_vf_setup(struct net_device *ndev,
  struct net_device *vf_netdev)
 {
@@ -1915,85 +1836,95 @@ static void netvsc_vf_setup(struct work_struct *w)
rtnl_unlock();
 }
 
-static int netvsc_register_vf(struct net_device *vf_netdev)
+static int netvsc_pre_register_vf(struct net_device *vf_netdev,
+ struct net_device *ndev)
 {
-   struct net_device *ndev;
struct net_device_context *net_device_ctx;
struct netvsc_device *netvsc_dev;
 
-   if (vf_netdev->addr_len != ETH_ALEN)
-   return NOTIFY_DONE;
-
-   /*
-* We will

[PATCH net-next v12 5/5] virtio_net: Extend virtio to use VF datapath when available

2018-05-24 Thread Sridhar Samudrala 
This patch enables virtio_net to switch over to a VF datapath when STANDBY
feature is enabled and a VF netdev is present with the same MAC address.
It allows live migration of a VM with a direct attached VF without the need
to setup a bond/team between a VF and virtio net device in the guest.

It uses the API that is exported by the net_failover driver to create and
and destroy a master failover netdev. When STANDBY feature is enabled, an
additional netdev(failover netdev) is created that acts as a master device
and tracks the state of the 2 lower netdevs. The original virtio_net netdev
is marked as 'standby' netdev and a passthru device with the same MAC is
registered as 'primary' netdev.

The hypervisor needs to unplug the VF device from the guest on the source
host and reset the MAC filter of the VF to initiate failover of datapath
to virtio before starting the migration. After the migration is completed,
the destination hypervisor sets the MAC filter on the VF and plugs it back
to the guest to switch over to VF datapath.

This patch is based on the discussion initiated by Jesse on this thread.
https://marc.info/?l=linux-virtualization=151189725224231=2

Signed-off-by: Sridhar Samudrala 
---
 Documentation/networking/net_failover.rst | 90 +++
 drivers/net/Kconfig   |  1 +
 drivers/net/virtio_net.c  | 38 -
 3 files changed, 128 insertions(+), 1 deletion(-)

diff --git a/Documentation/networking/net_failover.rst 
b/Documentation/networking/net_failover.rst
index d4513ad31809..70ca2f5800c4 100644
--- a/Documentation/networking/net_failover.rst
+++ b/Documentation/networking/net_failover.rst
@@ -24,3 +24,93 @@ This can be used by paravirtual drivers to enable an 
alternate low latency
 datapath. It also enables hypervisor controlled live migration of a VM with
 direct attached VF by failing over to the paravirtual datapath when the VF
 is unplugged.
+
+virtio-net accelerated datapath: STANDBY mode
+=
+
+net_failover enables hypervisor controlled accelerated datapath to virtio-net
+enabled VMs in a transparent manner with no/minimal guest userspace chanages.
+
+To support this, the hypervisor needs to enable VIRTIO_NET_F_STANDBY
+feature on the virtio-net interface and assign the same MAC address to both
+virtio-net and VF interfaces.
+
+Here is an example XML snippet that shows such configuration.
+
+ 
+   
+   
+   
+   
+   
+   
+   
+ 
+ 
+   
+   
+ 
+   
+   
+ 
+
+Booting a VM with the above configuration will result in the following 3
+netdevs created in the VM.
+
+4: ens10:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
+link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
+inet 192.168.12.53/24 brd 192.168.12.255 scope global dynamic ens10
+   valid_lft 42482sec preferred_lft 42482sec
+inet6 fe80::97d8:db2:8c10:b6d6/64 scope link
+   valid_lft forever preferred_lft forever
+5: ens10nsby:  mtu 1500 qdisc fq_codel master 
ens10 state UP group default qlen 1000
+link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
+7: ens11:  mtu 1500 qdisc mq master ens10 
state UP group default qlen 1000
+link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
+
+ens10 is the 'failover' master netdev, ens10nsby and ens11 are the slave
+'standby' and 'primary' netdevs respectively.
+
+Live Migration of a VM with SR-IOV VF & virtio-net in STANDBY mode
+==
+
+net_failover also enables hypervisor controlled live migration to be supported
+with VMs that have direct attached SR-IOV VF devices by automatic failover to
+the paravirtual datapath when the VF is unplugged.
+
+Here is a sample script that shows the steps to initiate live migration on
+the source hypervisor.
+
+# cat vf_xml
+
+  
+  
+
+  
+  
+
+
+# Source Hypervisor
+#!/bin/bash
+
+DOMAIN=fedora27-tap01
+PF=enp66s0f0
+VF_NUM=5
+TAP_IF=tap01
+VF_XML=
+
+MAC=52:54:00:00:12:53
+ZERO_MAC=00:00:00:00:00:00
+
+virsh domif-setlink $DOMAIN $TAP_IF up
+bridge fdb del $MAC dev $PF master
+virsh detach-device $DOMAIN $VF_XML
+ip link set $PF vf $VF_NUM mac $ZERO_MAC
+
+virsh migrate --live $DOMAIN qemu+ssh://$REMOTE_HOST/system
+
+# Destination Hypervisor
+#!/bin/bash
+
+virsh attach-device $DOMAIN $VF_XML
+virsh domif-setlink $DOMAIN $TAP_IF down
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2cdaff90a9ec..d03775100f7d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -332,6 +332,7 @@ config VETH
 config VIRTIO_NET
tristate "Virtio network driver"
depends on VIRTIO
+   select NET_FAILOVER
---help---
  This is the virtual network driver for virtio.  It can be used with
  QEMU based VMMs (like KVM or Xen).  Say Y or M.
diff --git a/drivers/net/virtio_net.c

[PATCH net-next v12 0/5] Enable virtio_net to act as a standby for a passthru device

2018-05-24 Thread Sridhar Samudrala 
The main motivation for this patch is to enable cloud service providers
to provide an accelerated datapath to virtio-net enabled VMs in a 
transparent manner with no/minimal guest userspace changes. This also
enables hypervisor controlled live migration to be supported with VMs that
have direct attached SR-IOV VF devices.

Patch 1 introduces a failover module that provides a generic interface for 
paravirtual drivers to listen for netdev register/unregister/link change
events from pci ethernet devices with the same MAC and takeover their
datapath. The notifier and event handling code is based on the existing
netvsc implementation. 

Patch 2 refactors netvsc to use the registration/notification framework
introduced by failover module.

Patch 3 introduces a net_failover driver that provides an automated
failover mechanism to paravirtual drivers via APIs to create and destroy
a failover master netdev and mananges a primary and standby slave netdevs
that get registered via the generic failover infrastructure.

Patch 4 introduces a new feature bit VIRTIO_NET_F_STANDBY to virtio-net
that can be used by hypervisor to indicate that virtio_net interface
should act as a standby for another device with the same MAC address.

Patch 5 extends virtio_net to use alternate datapath when available and
registered. When STANDBY feature is enabled, virtio_net driver uese the
net_failover API to create an additional 'failover' netdev that acts as
a master device and controls 2 slave devices.  The original virtio_net
netdev is registered as 'standby' netdev and a passthru/vf device with
the same MAC gets registered as 'primary' netdev. Both 'standby' and
'failover' netdevs are associated with the same 'pci' device.  The user
accesses the network interface via 'failover' netdev. The 'failover'
netdev chooses 'primary' netdev as default for transmits when it is
available with link up and running.

As this patch series is initially focusing on usecases where hypervisor 
fully controls the VM networking and the guest is not expected to directly 
configure any hardware settings, it doesn't expose all the ndo/ethtool ops
that are supported by virtio_net at this time. To support additional usecases,
it should be possible to enable additional ops later by caching the state
in failover netdev and replaying when the 'primary' netdev gets registered. 
 
At the time of live migration, the hypervisor needs to unplug the VF device
from the guest on the source host and reset the MAC filter of the VF to
initiate failover of datapath to virtio before starting the migration. After
the migration is completed, the destination hypervisor sets the MAC filter
on the VF and plugs it back to the guest to switch over to VF datapath.

This patch is based on the discussion initiated by Jesse on this thread.
https://marc.info/?l=linux-virtualization=151189725224231=2

v12:
- Tested live migration with virtio-net/AVF(i40evf) configured in failover
  mode while running iperf in background. Tried static ip and dhcp
  configurations using 'network' scripts and Network Manager.
- Build tested netvsc module.
Updates:
- Extended generic failover module to do common functions like setting
  FAILOVER_SLAVE flag, registering rx-handler and linking to upper dev in
  the generic register/unregister handlers.
  This required adding 3 additional failover ops pre_register, pre_unregister
  and handle_frame.  netvsc and net_failover drivers are updated to support
  these ops.

v11:
- Split net_failover module into 2 components.
  1. 'failover' module that provides generic failover infrastructure
  to register a failover instance and listen for slave events.
  2. 'net_failover' driver that provides APIs to create/destroy upper
  netdev and supports 3-netdev model used by virtio-net.
- Added documentation

v10:
- fix net_failover_open() to update failover CARRIER correctly based on
  standby and primary states. 
- fix net_failover_handle_frame() to handle frames received on standby
  when primary is present.
- replace netdev_upper_dev_link with netdev_master_upper_dev_link and
  handle lower dev state changes.
- fix net_failver_create() and net_failover_register() interfaces to
  use ERR_PTR and avoid arg **
- disable setting mac address when virtio-net in STANDBY mode
- document exported symbols
- added entry to MAINTAINERS file

v9:
Select NET_FAILOVER automatically when VIRTIO_NET/HYPERV_NET 
are enabled. (stephen)

v8:
- Made the failover managment routines more robust by updating the feature 
  bits/other fields in the failover netdev when slave netdevs are 
  registered/unregistered. (mst)
- added support for handling vlans.
- Limited the changes in netvsc to only use the notifier/event/lookups
  from the failover module. The slave register/unregister/link-change 
  handlers are only updated to use the getbymac routine to get the 
  upper netdev. There is no change in their functionality. (stephen)
- renamed structs/function/file names to use net_failover prefix.

Re: [PATCH v3 11/27] x86/power/64: Adapt assembly for PIE support

2018-05-24 Thread Thomas Garnier via Virtualization 
On Thu, May 24, 2018 at 4:04 AM Pavel Machek  wrote:

> On Wed 2018-05-23 12:54:05, Thomas Garnier wrote:
> > Change the assembly code to use only relative references of symbols for
the
> > kernel to be PIE compatible.
> >
> > Position Independent Executable (PIE) support will allow to extended the
> > KASLR randomization range below the -2G memory limit.
> >
> > Signed-off-by: Thomas Garnier 

> Again, was this tested?

Hibernation was tested as much as I can with qemu and my dedicated machine.
Any specific test you think I should use?


> > diff --git a/arch/x86/power/hibernate_asm_64.S
b/arch/x86/power/hibernate_asm_64.S
> > index ce8da3a0412c..6fdd7bbc3c33 100644
> > --- a/arch/x86/power/hibernate_asm_64.S
> > +++ b/arch/x86/power/hibernate_asm_64.S
> > @@ -24,7 +24,7 @@
> >  #include 
> >
> >  ENTRY(swsusp_arch_suspend)
> > - movq$saved_context, %rax
> > + leaqsaved_context(%rip), %rax
> >   movq%rsp, pt_regs_sp(%rax)
> >   movq%rbp, pt_regs_bp(%rax)
> >   movq%rsi, pt_regs_si(%rax)
> > @@ -115,7 +115,7 @@ ENTRY(restore_registers)
> >   movq%rax, %cr4;  # turn PGE back on
> >
> >   /* We don't restore %rax, it must be 0 anyway */
> > - movq$saved_context, %rax
> > + leaqsaved_context(%rip), %rax
> >   movqpt_regs_sp(%rax), %rsp
> >   movqpt_regs_bp(%rax), %rbp
> >   movqpt_regs_si(%rax), %rsi

> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



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

Re: [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

2018-05-24 Thread Thomas Garnier via Virtualization 
On Thu, May 24, 2018 at 4:03 AM Pavel Machek  wrote:

> On Wed 2018-05-23 12:54:03, Thomas Garnier wrote:
> > Change the assembly code to use only relative references of symbols for
the
> > kernel to be PIE compatible.
> >
> > Position Independent Executable (PIE) support will allow to extended the
> > KASLR randomization range below the -2G memory limit.

> What testing did this get?

Tested boot, hibernation and performance on qemu and dedicated machine.


> > diff --git a/arch/x86/kernel/acpi/wakeup_64.S
b/arch/x86/kernel/acpi/wakeup_64.S
> > index 50b8ed0317a3..472659c0f811 100644
> > --- a/arch/x86/kernel/acpi/wakeup_64.S
> > +++ b/arch/x86/kernel/acpi/wakeup_64.S
> > @@ -14,7 +14,7 @@
> >* Hooray, we are in Long 64-bit mode (but still running in low
memory)
> >*/
> >  ENTRY(wakeup_long64)
> > - movqsaved_magic, %rax
> > + movqsaved_magic(%rip), %rax
> >   movq$0x123456789abcdef0, %rdx
> >   cmpq%rdx, %rax
> >   jne bogus_64_magic

> Because, as comment says, this is rather tricky code.

I agree, I think maintainers feedback is very important for this patchset.


Pavel

> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



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

Re: [PATCH] block drivers/block: Use octal not symbolic permissions

2018-05-24 Thread Joe Perches 
On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote:
> On 5/23/18 4:35 PM, Joe Perches wrote:
> > On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
> > > On 5/23/18 2:05 PM, Joe Perches wrote:
> > > > Convert the S_ symbolic permissions to their octal equivalents as
> > > > using octal and not symbolic permissions is preferred by many as more
> > > > readable.
> > > > 
> > > > see: https://lkml.org/lkml/2016/8/2/1945
> > > > 
> > > > Done with automated conversion via:
> > > > $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
> > > > 
> > > > 
> > > > Miscellanea:
> > > > 
> > > > o Wrapped modified multi-line calls to a single line where appropriate
> > > > o Realign modified multi-line calls to open parenthesis
> > > 
> > > Honestly, I see this as pretty needless churn.
> > 
> > btw:
> > 
> > There is currently a mixture of symbolic and octal
> > permissions uses in block and drivers/block
> > 
> > ie: 94 octal and 146 symbolic uses.
> > 
> > If this is applied, all would become octal.
> 
> That does help justify the change. My main worry here is creating
> unnecessary conflicts, which is always annoying. But it's even more
> annoying when the change creating the conflict isn't really that
> important at all. Case in point, the patch doesn't apply to the
> for-4.18/block branch that it should go into...

Done against most recent -next as it's basically impossible
to do anything against multiple private trees.

Also, the script that generated the patch is in the changelog
so it's simple to rerun.


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

Re: [PATCH] block drivers/block: Use octal not symbolic permissions

2018-05-24 Thread Jens Axboe 
On 5/23/18 4:35 PM, Joe Perches wrote:
> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
>> On 5/23/18 2:05 PM, Joe Perches wrote:
>>> Convert the S_ symbolic permissions to their octal equivalents as
>>> using octal and not symbolic permissions is preferred by many as more
>>> readable.
>>>
>>> see: https://lkml.org/lkml/2016/8/2/1945
>>>
>>> Done with automated conversion via:
>>> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace 
>>>
>>> Miscellanea:
>>>
>>> o Wrapped modified multi-line calls to a single line where appropriate
>>> o Realign modified multi-line calls to open parenthesis
>>
>> Honestly, I see this as pretty needless churn.
> 
> btw:
> 
> There is currently a mixture of symbolic and octal
> permissions uses in block and drivers/block
> 
> ie: 94 octal and 146 symbolic uses.
> 
> If this is applied, all would become octal.

That does help justify the change. My main worry here is creating
unnecessary conflicts, which is always annoying. But it's even more
annoying when the change creating the conflict isn't really that
important at all. Case in point, the patch doesn't apply to the
for-4.18/block branch that it should go into...

-- 
Jens Axboe

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

Re: [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

2018-05-24 Thread Petr Mladek 
On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> When using -fPIE/PIC with function tracing, the compiler generates a
> call through the GOT (call *__fentry__@GOTPCREL). This instruction
> takes 6 bytes instead of 5 on the usual relative call.
> 
> If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
> so ftrace can handle the previous 5-bytes as before.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
> 
> Signed-off-by: Thomas Garnier 
> ---
>  arch/x86/include/asm/ftrace.h   |  6 +++--
>  arch/x86/include/asm/sections.h |  4 
>  arch/x86/kernel/ftrace.c| 42 +++--
>  3 files changed, 48 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index c18ed65287d5..8f2decce38d8 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
> @@ -25,9 +25,11 @@ extern void __fentry__(void);
>  static inline unsigned long ftrace_call_adjust(unsigned long addr)
>  {
>   /*
> -  * addr is the address of the mcount call instruction.
> -  * recordmcount does the necessary offset calculation.
> +  * addr is the address of the mcount call instruction. PIE has always a
> +  * byte added to the start of the function.
>*/
> + if (IS_ENABLED(CONFIG_X86_PIE))
> + addr -= 1;

This seems to modify the address even for modules that are _not_ compiled with
PIE, see below.

>   return addr;
>  }
>  
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 01ebcb6f263e..73b3c30cb7a3 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -135,6 +135,44 @@ ftrace_modify_code_direct(unsigned long ip, unsigned 
> const char *old_code,
>   return 0;
>  }
>  
> +/* Bytes before call GOT offset */
> +const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
> +
> +static int
> +ftrace_modify_initial_code(unsigned long ip, unsigned const char *old_code,
> +unsigned const char *new_code)
> +{
> + unsigned char replaced[MCOUNT_INSN_SIZE + 1];
> +
> + ftrace_expected = old_code;
> +
> + /*
> +  * If PIE is not enabled or no GOT call was found, default to the
> +  * original approach to code modification.
> +  */
> + if (!IS_ENABLED(CONFIG_X86_PIE) ||
> + probe_kernel_read(replaced, (void *)ip, sizeof(replaced)) ||
> + memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
> + return ftrace_modify_code_direct(ip, old_code, new_code);

And this looks like an attempt to handle modules compiled without
PIE. Does it works with the right ip in that case?

I wonder if a better solution would be to update
scripts/recordmcount.c to store the incremented location into the module.

IMPORTANT: I have only vague picture about how this all works. It is
possible that I am completely wrong. The code might be correct,
especially if you tested this situation.

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

Re: [PATCH v3 09/27] x86/acpi: Adapt assembly for PIE support

2018-05-24 Thread Pavel Machek 
On Wed 2018-05-23 12:54:03, Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.

What testing did this get?

> diff --git a/arch/x86/kernel/acpi/wakeup_64.S 
> b/arch/x86/kernel/acpi/wakeup_64.S
> index 50b8ed0317a3..472659c0f811 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -14,7 +14,7 @@
>* Hooray, we are in Long 64-bit mode (but still running in low memory)
>*/
>  ENTRY(wakeup_long64)
> - movqsaved_magic, %rax
> + movqsaved_magic(%rip), %rax
>   movq$0x123456789abcdef0, %rdx
>   cmpq%rdx, %rax
>   jne bogus_64_magic

Because, as comment says, this is rather tricky code.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [PATCH v3 11/27] x86/power/64: Adapt assembly for PIE support

2018-05-24 Thread Pavel Machek 
On Wed 2018-05-23 12:54:05, Thomas Garnier wrote:
> Change the assembly code to use only relative references of symbols for the
> kernel to be PIE compatible.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
> 
> Signed-off-by: Thomas Garnier 

Again, was this tested?

> diff --git a/arch/x86/power/hibernate_asm_64.S 
> b/arch/x86/power/hibernate_asm_64.S
> index ce8da3a0412c..6fdd7bbc3c33 100644
> --- a/arch/x86/power/hibernate_asm_64.S
> +++ b/arch/x86/power/hibernate_asm_64.S
> @@ -24,7 +24,7 @@
>  #include 
>  
>  ENTRY(swsusp_arch_suspend)
> - movq$saved_context, %rax
> + leaqsaved_context(%rip), %rax
>   movq%rsp, pt_regs_sp(%rax)
>   movq%rbp, pt_regs_bp(%rax)
>   movq%rsi, pt_regs_si(%rax)
> @@ -115,7 +115,7 @@ ENTRY(restore_registers)
>   movq%rax, %cr4;  # turn PGE back on
>  
>   /* We don't restore %rax, it must be 0 anyway */
> - movq$saved_context, %rax
> + leaqsaved_context(%rip), %rax
>   movqpt_regs_sp(%rax), %rsp
>   movqpt_regs_bp(%rax), %rbp
>   movqpt_regs_si(%rax), %rsi

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [PATCH v3 18/27] xen: Adapt assembly for PIE support

2018-05-24 Thread Juergen Gross 
On 23/05/18 21:54, Thomas Garnier wrote:
> Change the assembly code to use the new _ASM_MOVABS macro which get a
> symbol reference while being PIE compatible. Adapt the relocation tool
> to ignore 32-bit Xen code.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.
> 
> Signed-off-by: Thomas Garnier 

Reviewed-by: Juergen Gross 


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

Re: [RFC V2] virtio: Add platform specific DMA API translation for virito devices

2018-05-24 Thread Christoph Hellwig 
On Thu, May 24, 2018 at 08:27:04AM +1000, Benjamin Herrenschmidt wrote:
> - First qemu doesn't know that the guest will switch to "secure mode"
> in advance. There is no difference between a normal and a secure
> partition until the partition does the magic UV call to "enter secure
> mode" and qemu doesn't see any of it. So who can set the flag here ?
> 
> - Second, when using VIRTIO_F_IOMMU_PLATFORM, we also make qemu (or
> vhost) go through the emulated MMIO for every access to the guest,
> which adds additional overhead.

Also this whole scheme is simply the wrong way around.  No driver should
opt out of the DMA API in general.  For legacy reasons we might have to
opt out of the dma API for some virtio cases due to qemu bugs, but
this should never have been the default, but a quirk for the affected
versions.

We need to fix this now and make the dma ops bypass the quirk instead of
the default, which will also solve the power issue.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization