On Wed, Feb 25, 2015 at 12:49 PM, David Rientjes rient...@google.com wrote:
Woohoo, so does this mean that Luis's series will finally be merged into a
tree somewhere? It's been a lengthy wait to try to get this merged.
David Rientjes (as I'm also Cc'ing David Vrabel),
I am reworking Xen's
On Wed, Feb 25, 2015 at 1:19 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Wed, Feb 25, 2015 at 01:11:04PM -0800, David Rientjes wrote:
On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
I am reworking Xen's kconfig stuff right now, so perhaps what is best
is for this series
On Tue, Feb 10, 2015 at 05:23:29PM -0800, David Rientjes wrote:
On Tue, 10 Feb 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64
From: Luis R. Rodriguez mcg...@suse.com
Resending to the maintainers that it was recommended to try.
Ingo, Thomas, Andrew, who should this go through? Please note
that the Kconfig maintainer is not available anymore and it
was recommended this go through that person first, meanwhile
while
From: Luis R. Rodriguez mcg...@suse.com
We'll be adding options for xen as well.
Cc: Josh Triplett j...@joshtriplett.org
Cc: Borislav Petkov b...@suse.de
Cc: Pekka Enberg penb...@kernel.org
Cc: David Rientjes rient...@google.com
Cc: Michal Marek mma...@suse.cz
Cc: Randy Dunlap rdun
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared
From: Luis R. Rodriguez mcg...@suse.com
The general documentation we have for pv_ops is currenty present
on the IA64 docs, but since this documentation covers IA64 xen
enablement and IA64 Xen support got ripped out a while ago
through commit d52eefb47 present since v3.14-rc1 lets just
simplify
On Tue, Feb 10, 2015 at 04:49:13PM -0800, David Rientjes wrote:
On Tue, 10 Feb 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64
From: Luis R. Rodriguez mcg...@suse.com
This v4 addresses the missing CONFIG_HYPERVISOR_GUEST and
CONFIG_PARAVIRT as noted by David.
Luis R. Rodriguez (2):
x86, platform, xen, kconfig: clarify kvmconfig is for kvm
x86, arm, platform, xen, kconfig: add xen defconfig helper
arch/x86/configs
From: Luis R. Rodriguez mcg...@suse.com
We'll be adding options for xen as well.
Cc: Josh Triplett j...@joshtriplett.org
Cc: Borislav Petkov b...@suse.de
Cc: Pekka Enberg penb...@kernel.org
Cc: David Rientjes rient...@google.com
Cc: Michal Marek mma...@suse.cz
Cc: Randy Dunlap rdun
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared
On Mon, Feb 2, 2015 at 1:32 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Mon, Feb 2, 2015 at 1:13 PM, Michal Marek mma...@suse.cz wrote:
Dne 30.1.2015 v 19:25 Luis R. Rodriguez napsal(a):
On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek mma...@suse.cz wrote:
On 2015-01-29 21:47, Paul
On Thu, Feb 05, 2015 at 12:47:15PM +, David Vrabel wrote:
On 27/01/15 01:51, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v5 nukes tracing as David said it was useless, it also
only adds support for 64-bit as its the only thing I can test,
and slightly
On Tue, Feb 03, 2015 at 11:05:15AM +, David Vrabel wrote:
On 27/01/15 01:51, Luis R. Rodriguez wrote:
+#ifndef CONFIG_PREEMPT
+extern struct { char _entry[32]; } preemptible_hypercall_page[];
+
+static inline bool xen_is_preemptible_hypercall(struct pt_regs *regs)
+{
+ return
On Mon, Feb 2, 2015 at 1:13 PM, Michal Marek mma...@suse.cz wrote:
Dne 30.1.2015 v 19:25 Luis R. Rodriguez napsal(a):
On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek mma...@suse.cz wrote:
On 2015-01-29 21:47, Paul Bolle wrote:
[Added Michal. Removed Yann.]
On Thu, 2015-01-29 at 12:38 -0800
On Thu, Jan 29, 2015 at 12:35 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Jan 27, 2015 at 10:06:44AM +, David Vrabel wrote:
On 27/01/15 08:35, Jan Beulich wrote:
On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote:
Even if David told you this would be acceptable, I have
On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek mma...@suse.cz wrote:
On 2015-01-29 21:47, Paul Bolle wrote:
[Added Michal. Removed Yann.]
On Thu, 2015-01-29 at 12:38 -0800, Luis R. Rodriguez wrote:
On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Jan 23, 2015
On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg
On Tue, Jan 27, 2015 at 10:06:44AM +, David Vrabel wrote:
On 27/01/15 08:35, Jan Beulich wrote:
On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this
On Tue, Jan 27, 2015 at 10:06:44AM +, David Vrabel wrote:
On 27/01/15 08:35, Jan Beulich wrote:
On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this
On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v3 addresses Stefano's feedback from the v2 series, namely
On Thu, Jan 22, 2015 at 05:40:45PM -0800, Andy Lutomirski wrote:
On Thu, Jan 22, 2015 at 4:29 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued
From: Luis R. Rodriguez mcg...@suse.com
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls continuation [0]. Despite this though without
CONFIG_PREEMPT preemption won't happen, without preemption
a system can
From: Luis R. Rodriguez mcg...@suse.com
This v5 nukes tracing as David said it was useless, it also
only adds support for 64-bit as its the only thing I can test,
and slightly modifies the documentation in code as to why we
want this. The no krobe thing is left in place as I haven't
heard
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around as it addresses sub-operatiosn in kernel
context (multicalls). Such operations can trigger soft lockup
detection.
We want
On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls
On Fri, Jan 23, 2015 at 11:30:16AM +, David Vrabel wrote:
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around
On Fri, Jan 23, 2015 at 11:51:09AM +, David Vrabel wrote:
On 23/01/15 00:29, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v4 addresses some of the cleanups recommended and adds
tracing option for when we do actually preempt a hypercall.
I kept
On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
+ */
+void xen_end_upcall(struct pt_regs *regs)
+{
+ if (xen_is_preemptible_hypercall(regs)) {
+ int cpuid = smp_processor_id();
+ if (_cond_resched())
+
On Thu, Jan 22, 2015 at 08:56:49AM -0500, Steven Rostedt wrote:
On Thu, 22 Jan 2015 11:50:10 +
Andrew Cooper andrew.coop...@citrix.com wrote:
On 22/01/15 02:17, Luis R. Rodriguez wrote:
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -32,6 +32,8
On Thu, Jan 22, 2015 at 11:50:10AM +, Andrew Cooper wrote:
On 22/01/15 02:17, Luis R. Rodriguez wrote:
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -32,6 +32,8 @@
#include linux/slab.h
#include linux/irqnr.h
#include linux/pci.h
+#include
On Thu, Jan 22, 2015 at 01:10:49PM +, Julien Grall wrote:
Hi Luis,
On 22/01/15 02:17, Luis R. Rodriguez wrote:
diff --git a/drivers/xen/events/events_base.c
b/drivers/xen/events/events_base.c
index b4bca2d..23c526b 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen
On Thu, Jan 22, 2015 at 09:44:12PM +, Andrew Cooper wrote:
On 22/01/2015 21:09, Luis R. Rodriguez wrote:
On Thu, Jan 22, 2015 at 12:01:50PM -0800, Andy Lutomirski wrote:
On Thu, Jan 22, 2015 at 11:30 AM, Luis R. Rodriguez mcg...@suse.com
wrote:
On Wed, Jan 21, 2015 at 07:07:36PM
From: Luis R. Rodriguez mcg...@suse.com
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls continuation [0]. Despite this though without
CONFIG_PREEMPT preemption won't happen, without preemption
a system can
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around as it addresses sub-operatiosn in kernel
context (multicalls). Such operations can trigger soft lockup
detection.
We want
From: Luis R. Rodriguez mcg...@suse.com
This v4 addresses some of the cleanups recommended and adds
tracing option for when we do actually preempt a hypercall.
I kept the NOKPROBE_SYMBOL() for now but did remove the 'notrace'
stuff.
This goes out as RFC still as I have not been able to test 32
On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This v3 addresses Stefano's feedback from the v2 series, namely
moving PCI stuff to x86 as its all x86 specific and also just
removing the CONFIG_TCG_XEN=m from the general config
On Wed, Jan 21, 2015 at 07:18:46PM -0800, Andy Lutomirski wrote:
On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls
On Wed, Jan 21, 2015 at 07:07:36PM -0800, Andy Lutomirski wrote:
On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued
On Thu, Jan 22, 2015 at 12:55:17PM +, David Vrabel wrote:
On 22/01/15 03:18, Andy Lutomirski wrote:
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -32,6 +32,8 @@
#include linux/slab.h
#include linux/irqnr.h
#include linux/pci.h
+#include
On Thu, Jan 22, 2015 at 12:01:50PM -0800, Andy Lutomirski wrote:
On Thu, Jan 22, 2015 at 11:30 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Wed, Jan 21, 2015 at 07:07:36PM -0800, Andy Lutomirski wrote:
On Wed, Jan 21, 2015 at 6:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote
From: Luis R. Rodriguez mcg...@suse.com
On kernels with voluntary or no preemption we can run
into situations where a hypercall issued through userspace
will linger around as it addresses sub-operatiosn in kernel
context (multicalls). Such operations can trigger soft lockup
detection.
We want
From: Luis R. Rodriguez mcg...@suse.com
Xen has support for splitting heavy work work into a series
of hypercalls, called multicalls, and preempting them through
what Xen calls continuation [0]. Despite this though without
CONFIG_PREEMPT preemption won't happen, without preemption
a system can
From: Luis R. Rodriguez mcg...@suse.com
After my last respin Andy provided some ideas as how to skip
IRQ context hacks for preemption, this v3 spin addresses that
and a bit more.
This is based on both Andrew Cooper's and David Vrabel's work,
further modified based on ideas by Andy Lutomirski
From: Luis R. Rodriguez mcg...@suse.com
This v3 addresses Stefano's feedback from the v2 series, namely
moving PCI stuff to x86 as its all x86 specific and also just
removing the CONFIG_TCG_XEN=m from the general config. To be
clear the changes from the v2 series are below.
Luis R. Rodriguez (2
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared
From: Luis R. Rodriguez mcg...@suse.com
We'll be adding options for xen as well.
Cc: Josh Triplett j...@joshtriplett.org
Cc: Borislav Petkov b...@suse.de
Cc: Pekka Enberg penb...@kernel.org
Cc: David Rientjes rient...@google.com
Cc: Michal Marek mma...@suse.cz
Cc: Randy Dunlap rdun
On Wed, Jan 14, 2015 at 11:29:41AM +, Stefano Stabellini wrote:
On Tue, 13 Jan 2015, Luis R. Rodriguez wrote:
On Mon, Dec 15, 2014 at 02:58:26PM +, Stefano Stabellini wrote:
On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets
On Mon, Dec 15, 2014 at 02:58:26PM +, Stefano Stabellini wrote:
On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64
On Mon, Dec 15, 2014 at 11:58:34AM +, Julien Grall wrote:
Hello Luis,
On 09/12/14 23:35, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86
On Tue, Jan 13, 2015 at 11:13 AM, Julien Grall julien.gr...@linaro.org wrote:
Stefano had some comments on this patch. See:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01531.html
I see now sorry about that, will address and respin.
Luis
--
To unsubscribe from this list:
On Tue, Dec 9, 2014 at 12:22 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
If you are sure then yes.
Likewise here.
Luis
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall julien.gr...@linaro.org wrote:
Hello Luis,
On 08/12/2014 23:05, Luis R. Rodriguez wrote:
diff --git a/kernel/configs/xen.config b/kernel/configs/xen.config
new file mode 100644
index 000..0d0eb6d
--- /dev/null
+++ b/kernel/configs
On Tue, Dec 9, 2014 at 12:37 PM, Julien Grall julien.gr...@linaro.org wrote:
On 09/12/14 20:22, Luis R. Rodriguez wrote:
On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall julien.gr...@linaro.org wrote:
Hello Luis,
On 08/12/2014 23:05, Luis R. Rodriguez wrote:
diff --git a/kernel/configs
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared
From: Luis R. Rodriguez mcg...@suse.com
This v2 addreses some minor feedback on patch 2, and just
mends in the review tags.
Luis R. Rodriguez (2):
x86, platform, xen, kconfig: clarify kvmconfig is for kvm
x86, arm, platform, xen, kconfig: add xen defconfig helper
arch/x86/configs
From: Luis R. Rodriguez mcg...@suse.com
We'll be adding options for xen as well.
Cc: Josh Triplett j...@joshtriplett.org
Cc: Borislav Petkov b...@suse.de
Cc: Pekka Enberg penb...@kernel.org
Cc: David Rientjes rient...@google.com
Cc: Michal Marek mma...@suse.cz
Cc: Randy Dunlap rdun
From: Luis R. Rodriguez mcg...@suse.com
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared
From: Luis R. Rodriguez mcg...@suse.com
We'll be adding options for xen as well.
Cc: Josh Triplett j...@joshtriplett.org
Cc: Borislav Petkov b...@suse.de
Cc: Pekka Enberg penb...@kernel.org
Cc: David Rientjes rient...@google.com
Cc: Michal Marek mma...@suse.cz
Cc: Randy Dunlap rdun
From: Luis R. Rodriguez mcg...@suse.com
This is based on some old set I had lying around. The virtconfig
changes I had proposed a while ago got merged and reused for
tinyconfig, this adapts my original set to use the new mergeconfig.
Not sure who's tree this should go through, last time
On Wed, Dec 03, 2014 at 08:39:47PM +0100, Luis R. Rodriguez wrote:
On Wed, Dec 03, 2014 at 05:37:51AM +0100, Juergen Gross wrote:
On 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
On Tue, Dec 02, 2014 at 11:11:18AM +, David Vrabel wrote:
On 01/12/14 22:36, Luis R. Rodriguez wrote
On Wed, Dec 03, 2014 at 05:37:51AM +0100, Juergen Gross wrote:
On 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
On Tue, Dec 02, 2014 at 11:11:18AM +, David Vrabel wrote:
On 01/12/14 22:36, Luis R. Rodriguez wrote:
Then I do agree its a fair analogy (and find this obviously odd that how
On Tue, Dec 02, 2014 at 11:11:18AM +, David Vrabel wrote:
On 01/12/14 22:36, Luis R. Rodriguez wrote:
Then I do agree its a fair analogy (and find this obviously odd that how
widespread cond_resched() is), we just don't have an equivalent for IRQ
context, why not avoid the special
On Mon, Dec 01, 2014 at 11:01:18AM +, David Vrabel wrote:
On 28/11/14 04:49, Juergen Gross wrote:
On 11/27/2014 07:50 PM, Andrew Cooper wrote:
XenServer uses
https://github.com/xenserver/linux-3.x.pg/blob/master/master/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch
On Mon, Dec 01, 2014 at 11:11:43AM +, David Vrabel wrote:
On 27/11/14 18:36, Luis R. Rodriguez wrote:
On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Some folks had reported
On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel david.vra...@citrix.com wrote:
On 01/12/14 15:05, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014 at 11:11:43AM +, David Vrabel wrote:
On 27/11/14 18:36, Luis R. Rodriguez wrote:
On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote
On Mon, Dec 01, 2014 at 03:42:33PM +0100, Juergen Gross wrote:
On 12/01/2014 02:32 PM, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014 at 11:01:18AM +, David Vrabel wrote:
On 28/11/14 04:49, Juergen Gross wrote:
On 11/27/2014 07:50 PM, Andrew Cooper wrote:
XenServer uses
https
On Mon, Dec 01, 2014 at 03:54:24PM +, David Vrabel wrote:
On 01/12/14 15:44, Luis R. Rodriguez wrote:
On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel david.vra...@citrix.com
wrote:
On 01/12/14 15:05, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014 at 11:11:43AM +, David Vrabel wrote
On Mon, Dec 01, 2014 at 06:07:48PM +0100, Juergen Gross wrote:
On 12/01/2014 05:19 PM, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014 at 03:54:24PM +, David Vrabel wrote:
On 01/12/14 15:44, Luis R. Rodriguez wrote:
On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel david.vra...@citrix.com
On Mon, Dec 01, 2014 at 06:16:28PM +, David Vrabel wrote:
On 01/12/14 16:19, Luis R. Rodriguez wrote:
On Mon, Dec 01, 2014 at 03:54:24PM +, David Vrabel wrote:
On 01/12/14 15:44, Luis R. Rodriguez wrote:
On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel david.vra...@citrix.com
wrote
On Thu, Nov 27, 2014 at 06:50:31PM +, Andrew Cooper wrote:
On 27/11/14 18:36, Luis R. Rodriguez wrote:
On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Some folks had reported
On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Some folks had reported that some xen hypercalls take a long time
to complete when issued from the userspace private ioctl mechanism
On Thu, Nov 27, 2014 at 1:36 PM, Luis R. Rodriguez mcg...@suse.com wrote:
I'm afraid we don't have much leg room.
Let me be clear, I still think putting some hypercalls in process
context *might help* but because of notes 1) and 2) I highlighted I
think this is the best we can do, with more
From: Luis R. Rodriguez mcg...@suse.com
Some folks had reported that some xen hypercalls take a long time
to complete when issued from the userspace private ioctl mechanism,
this can happen for instance with some hypercalls that have many
sub-operations, this can happen for instance on hypercalls
On Tue, Apr 22, 2014 at 12:43 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Mar 18, 2014 at 02:22:43PM -0700, Luis R. Rodriguez wrote:
On Tue, Mar 18, 2014 at 01:46:49PM -0700, Cong Wang wrote:
On Fri, Mar 14, 2014 at 6:39 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Mar 13
On Tue, Apr 22, 2014 at 12:41 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
Stephen, I'd like to respin this series to address all pending
feedback, I'd still like your feedback / call / judgement on this
part. I'm fine either way, just wanted to ensure I highlight the
reasoning of why
On Wed, Apr 30, 2014 at 04:04:34PM -0400, Vlad Yasevich wrote:
On 04/22/2014 03:43 PM, Luis R. Rodriguez wrote:
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 54d207d..dcd9378 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -315,6 +315,8 @@ netdev_features_t
On Wed, Mar 19, 2014 at 7:05 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Mar 18, 2014 at 08:10:56PM -0700, Stephen Hemminger wrote:
On Wed, 12 Mar 2014 20:15:25 -0700
Luis R. Rodriguez mcg...@do-not-panic.com wrote:
As it is now if you add create a bridge it gets started
On Tue, Mar 18, 2014 at 02:22:43PM -0700, Luis R. Rodriguez wrote:
On Tue, Mar 18, 2014 at 01:46:49PM -0700, Cong Wang wrote:
On Fri, Mar 14, 2014 at 6:39 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Mar 13, 2014 at 11:26:25AM -0700, Cong Wang wrote:
On Wed, Mar 12, 2014 at 8:15
On Tue, Mar 18, 2014 at 08:10:56PM -0700, Stephen Hemminger wrote:
On Wed, 12 Mar 2014 20:15:25 -0700
Luis R. Rodriguez mcg...@do-not-panic.com wrote:
As it is now if you add create a bridge it gets started
with a random MAC address and if you then add a net_device
as a slave but later
On Wed, Mar 12, 2014 at 8:15 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
Here's a few fixes I've been carrying around. I've now tested them
on as many systems / environments as I can. They should be ready.
Luis R. Rodriguez (3):
bridge: preserve random init MAC address
bridge
On Tue, Mar 18, 2014 at 01:46:49PM -0700, Cong Wang wrote:
On Fri, Mar 14, 2014 at 6:39 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Mar 13, 2014 at 11:26:25AM -0700, Cong Wang wrote:
On Wed, Mar 12, 2014 at 8:15 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote
On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
makita.toshi...@lab.ntt.co.jp wrote:
nit,
If the last detached port happens to have the same addr as
random_init_addr, this seems to call br_stp_change_bridge_id() even
though bridge_id is not changed.
Ah good point.
Shouldn't the assignment
On Tue, Mar 18, 2014 at 6:04 PM, Toshiaki Makita
makita.toshi...@lab.ntt.co.jp wrote:
(2014/03/19 9:50), Luis R. Rodriguez wrote:
On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
makita.toshi...@lab.ntt.co.jp wrote:
nit,
If the last detached port happens to have the same addr
On Tue, Mar 18, 2014 at 8:10 PM, Stephen Hemminger
step...@networkplumber.org wrote:
On Wed, 12 Mar 2014 20:15:25 -0700
Luis R. Rodriguez mcg...@do-not-panic.com wrote:
As it is now if you add create a bridge it gets started
with a random MAC address and if you then add a net_device
On Thu, Mar 13, 2014 at 11:26:25AM -0700, Cong Wang wrote:
On Wed, Mar 12, 2014 at 8:15 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
spin_lock_bh(p-br-lock);
err = br_setport(p, tb);
+ changed
On Thu, Mar 13, 2014 at 03:16:23PM -0700, Stephen Hemminger wrote:
On Wed, 12 Mar 2014 20:15:27 -0700
Luis R. Rodriguez mcg...@do-not-panic.com wrote:
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -150,6 +150,7 @@ struct net_bridge_port
u8
From: Luis R. Rodriguez mcg...@suse.com
If netlink is used to tune a port we currently don't trigger a
new recalculation of the bridge id, ensure that happens just as
if we're adding a new net_device onto the bridge.
Cc: Stephen Hemminger step...@networkplumber.org
Cc: bri...@lists.linux
From: Luis R. Rodriguez mcg...@suse.com
As it is now if you add create a bridge it gets started
with a random MAC address and if you then add a net_device
as a slave but later kick it out you end up with a zero
MAC address. Instead preserve the original random MAC
address and use it.
If you
From: Luis R. Rodriguez mcg...@suse.com
Root port blocking was designed so that a bridge port can opt
out of becoming the designated root port for a bridge. If a port
however first becomes the designated root port and we then toggle
the root port block on it we currently don't kick that port out
Here's a few fixes I've been carrying around. I've now tested them
on as many systems / environments as I can. They should be ready.
Luis R. Rodriguez (3):
bridge: preserve random init MAC address
bridge: trigger a bridge calculation upon port changes
bridge: fix bridge root block
From: Luis R. Rodriguez mcg...@suse.com
The networking bridge module allows us to specify a
root block preference on net_devices but this feature
is a bridge port primitive. The bridge module assumes
that once a device is added as a slave to the brige
that it can be considered for the the root
From: Luis R. Rodriguez mcg...@suse.com
The purpose of using a static MAC address of FE:FF:FF:FF:FF:FF
was to prevent our backend interfaces from being used by the
bridge and nominating our interface as a root port on the bridge.
This was possible given that the bridge code will use the lowest
From: Luis R. Rodriguez mcg...@suse.com
Root port blocking was designed so that a bridge port can opt
out of becoming the designated root port for a bridge. If a port
however first becomes the designated root port and we then toggle
the root port block on it we currently don't kick that port out
From: Luis R. Rodriguez mcg...@suse.com
root block support was added via 1007dd1a on v3.8 but toggling
this flag is only allowed after a device has been registered and
added to a bridge as its a bridge *port* primitive, not a *net_device*
feature. There are work arounds possible to account
From: Luis R. Rodriguez mcg...@suse.com
If netlink is used to tune a port we currently don't trigger a
new recalculation of the bridge id, ensure that happens just as
if we're adding a new net_device onto the bridge.
Cc: Stephen Hemminger step...@networkplumber.org
Cc: bri...@lists.linux
From: Luis R. Rodriguez mcg...@suse.com
This is my third series on addressing removing the xen-netback hack of
using a high MAC address for a root block preference after feedback and
testing of the bridge feature Stephen mentioned. We want to remove that
hack as its possible to end up with IPv6
From: Luis R. Rodriguez mcg...@suse.com
As it is now if you add create a bridge it gets started
with a random MAC address and if you then add a net_device
as a slave but later kick it out you end up with a zero
MAC address. Instead preserve the original random MAC
address and use it.
If you
On Mon, Mar 3, 2014 at 3:43 PM, Stephen Hemminger
step...@networkplumber.org wrote:
Doing this in priv flags bloats what is a limited resource (# of bits).
Agreed. I tried to avoid it but saw no other option for addressing
this during initialization properly without requirng a userspace
upgrade.
On Mon, Mar 3, 2014 at 4:31 PM, Stephen Hemminger
step...@networkplumber.org wrote:
On Mon, 3 Mar 2014 15:58:50 -0800
Luis R. Rodriguez mcg...@do-not-panic.com wrote:
On Mon, Mar 3, 2014 at 3:43 PM, Stephen Hemminger
step...@networkplumber.org wrote:
Doing this in priv flags bloats what
1 - 100 of 132 matches
Mail list logo
