), we
can unconditionally clear the doorbell message in
kvmppc_check_wake_reason.
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerp
On Wed, Feb 25, 2015 at 1:19 PM, Konrad Rzeszutek Wilk
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
>> >
On Wed, Feb 25, 2015 at 12:49 PM, David Rientjes 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 kconfig stuff right
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"
> >
> > This lets you build a kernel which can support xen dom0
> > or xen guests by just using:
> >
From: "Luis R. Rodriguez"
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' u
From: "Luis R. Rodriguez"
We'll be adding options for xen as well.
Cc: Josh Triplett
Cc: Borislav Petkov
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Michal Marek
Cc: Randy Dunlap
Cc: penb...@kernel.org
Cc: levinsasha...@gmail.com
Cc: mtosa...@redhat.com
Cc: fengguang...@inte
From: "Luis R. Rodriguez"
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/
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"
> >
> > This lets you build a kernel which can support xen dom0
> > or xen guests by just using:
> >
From: "Luis R. Rodriguez"
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, gene
From: "Luis R. Rodriguez"
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' u
From: "Luis R. Rodriguez"
We'll be adding options for xen as well.
Cc: Josh Triplett
Cc: Borislav Petkov
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Michal Marek
Cc: Randy Dunlap
Cc: penb...@kernel.org
Cc: levinsasha...@gmail.com
Cc: mtosa...@redhat.com
Cc: fengguang...@inte
From: "Luis R. Rodriguez"
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 that is
On Mon, Feb 2, 2015 at 1:32 PM, Luis R. Rodriguez
wrote:
> On Mon, Feb 2, 2015 at 1:13 PM, Michal Marek wrote:
>> Dne 30.1.2015 v 19:25 Luis R. Rodriguez napsal(a):
>>> On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek wrote:
>>>> On 2015-01-29 21:47, Paul Bolle wrote
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"
> >
> > This v5 nukes tracing as David said it was useless, it also
> > only adds support for 64-bit as its the on
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_preemptib
On Thu, Jan 29, 2015 at 12:35 PM, Luis R. Rodriguez 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, wrote:
>> >
>> > Even if David told you this would be ac
On Mon, Feb 2, 2015 at 1:13 PM, Michal Marek wrote:
> Dne 30.1.2015 v 19:25 Luis R. Rodriguez napsal(a):
>> On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek wrote:
>>> On 2015-01-29 21:47, Paul Bolle wrote:
>>>> [Added Michal. Removed Yann.]
>>>>
>
On Fri, Jan 30, 2015 at 2:49 AM, Michal Marek 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 wrote:
>>&
On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez 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:
>> >
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, 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 may
> > be acc
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, 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 may
> > be acc
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"
> > >
> > > This v3 addresses
From: "Luis R. Rodriguez"
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 ca
From: "Luis R. Rodriguez"
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 c
From: "Luis R. Rodriguez"
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 to
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
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > On kernels with voluntary or no preemption we can run
> > into situations where a hyp
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())
> > + trace_xen_hyper
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"
> >
> > This v4 addresses some of the cleanups recommended and adds
> > tracing option for when we do actuall
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"
> >
> > On kernels with voluntary or no preemption we can run
> > into situations where a hypercall issued through u
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"
> >
> > Xen has support for splitting heavy work work into a series
> > of hypercalls, called multicalls, and preem
On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> 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: "Luis R. Rodriguez"
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 ca
From: "Luis R. Rodriguez"
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 to
From: "Luis R. Rodriguez"
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
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
> >> wrote:
> >>> O
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 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
> >> wrote:
>
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
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > Xen has support for splitting heavy work work into a series
> > of hypercalls, called
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
> wrote:
> > From: "Luis R. Rodriguez"
> >
> > On kernels with voluntary or no preemption we can run
> > into situations where a hyp
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/x
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
> > #include
> >
On Thu, Jan 22, 2015 at 08:56:49AM -0500, Steven Rostedt wrote:
> On Thu, 22 Jan 2015 11:50:10 +
> Andrew Cooper wrote:
>
> > On 22/01/15 02:17, Luis R. Rodriguez wrote:
> > > --- a/drivers/xen/events/events_base.c
> > > +++ b/drivers/xen/events/e
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
> >> #include
> >> #include
> >> +#include
> >> +#include
>
From: "Luis R. Rodriguez"
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 ca
From: "Luis R. Rodriguez"
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 Lutomi
From: "Luis R. Rodriguez"
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 to
From: "Luis R. Rodriguez"
We'll be adding options for xen as well.
Cc: Josh Triplett
Cc: Borislav Petkov
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Michal Marek
Cc: Randy Dunlap
Cc: penb...@kernel.org
Cc: levinsasha...@gmail.com
Cc: mtosa...@redhat.com
Cc: fengguang...@inte
From: "Luis R. Rodriguez"
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. Rodri
From: "Luis R. Rodriguez"
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' u
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
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"
> >
> > This lets you build a kernel which can support xen dom0
> > or xen guests by just using:
> >
>
On Tue, Jan 13, 2015 at 11:13 AM, Julien Grall 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: send the line "unsubscr
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"
> >
> > This lets you build a kernel which can support xen dom0
> > or xen guests by just using:
From: "Luis R. Rodriguez"
We'll be adding options for xen as well.
Cc: Josh Triplett
Cc: Borislav Petkov
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Michal Marek
Cc: Randy Dunlap
Cc: penb...@kernel.org
Cc: levinsasha...@gmail.com
Cc: mtosa...@redhat.com
Cc: fengguang...@inte
From: "Luis R. Rodriguez"
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' u
From: "Luis R. Rodriguez"
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/xen.c
On Tue, Dec 9, 2014 at 12:37 PM, Julien Grall wrote:
> On 09/12/14 20:22, Luis R. Rodriguez wrote:
>> On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall wrote:
>>> Hello Luis,
>>>
>>> On 08/12/2014 23:05, Luis R. Rodriguez wrote:
>>>>
>>>
On Tue, Dec 9, 2014 at 12:22 PM, Luis R. Rodriguez
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/majordomo-info.html
On Tue, Dec 9, 2014 at 1:06 AM, Julien Grall 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/
From: "Luis R. Rodriguez"
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 the
From: "Luis R. Rodriguez"
We'll be adding options for xen as well.
Cc: Josh Triplett
Cc: Borislav Petkov
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Michal Marek
Cc: Randy Dunlap
Cc: penb...@kernel.org
Cc: levinsasha...@gmail.com
Cc: mtosa...@redhat.com
Cc: fengguang...@inte
From: "Luis R. Rodriguez"
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' u
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/
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 i
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
>
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
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
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
> > wrote:
> >> On 01/12/14 15:05, Luis R. Rodriguez wrote:
> >>> On Mon, Dec 01, 2014 at 11:11:43AM
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 Coope
On Mon, Dec 1, 2014 at 10:18 AM, David Vrabel 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, Juerg
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&qu
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-preem
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&qu
On Thu, Nov 27, 2014 at 1:36 PM, Luis R. Rodriguez 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 i
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"
>>
>> Some folks had reported that some xen hypercalls take a long time
>> to complete when issued from the userspace
From: "Luis R. Rodriguez"
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 hypercall
On 07/03/2014 11:42 AM, Hongyang Yang wrote:
I wonder if there is anyway to coordinate this between COLO, Michael
Hines microcheckpointing and the two separate reverse-execution
projects that also need to do some similar things.
Are there any standard APIs for the heartbeet thing we can already
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/b
On Tue, Apr 22, 2014 at 12:41 PM, Luis R. Rodriguez
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
On Tue, Apr 22, 2014 at 12:43 PM, Luis R. Rodriguez 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 wrote:
>> > > On T
On Wed, Mar 19, 2014 at 7:05 PM, Luis R. Rodriguez 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" wrote:
>>
>> > As it is now if you add create a bridge it gets start
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 wrote:
> > > On Thu, Mar 13, 2014 at 11:26:25AM -0700, Cong Wang wrote:
> > >> O
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" 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 Tue, Mar 18, 2014 at 8:10 PM, Stephen Hemminger
wrote:
> On Wed, 12 Mar 2014 20:15:25 -0700
> "Luis R. Rodriguez" 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 s
On Tue, Mar 18, 2014 at 6:04 PM, Toshiaki Makita
wrote:
> (2014/03/19 9:50), Luis R. Rodriguez wrote:
>> On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
>> wrote:
>>> nit,
>>> If the last detached port happens to have the same addr as
>>
On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
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 of random_init_addr be do
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 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
> >> wrote:
> >> >
On Wed, Mar 12, 2014 at 8:15 PM, Luis R. Rodriguez
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 addres
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" wrote:
>
> > --- a/net/bridge/br_private.h
> > +++ b/net/bridge/br_private.h
> > @@ -150,6 +150,7
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
> wrote:
> > spin_lock_bh(&p->br->lock);
> > err = br_setport(p, tb);
> > + chan
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 bridg
From: "Luis R. Rodriguez"
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 manual
From: "Luis R. Rodriguez"
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
From: "Luis R. Rodriguez"
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
Cc: bri...@lists.linux-foundation.org
Cc: net..
On Mon, Mar 3, 2014 at 2:46 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
<-- snip -->
> As I tested using the root block preference I noticed that if a net_device
> slave under the bridge gets the designated root port prior to setting in
> userspace the
On Mon, Mar 3, 2014 at 4:31 PM, Stephen Hemminger
wrote:
> On Mon, 3 Mar 2014 15:58:50 -0800
> "Luis R. Rodriguez" wrote:
>
>> On Mon, Mar 3, 2014 at 3:43 PM, Stephen Hemminger
>> wrote:
>> > Doing this in priv flags bloats what is a limited resource (#
On Mon, Mar 3, 2014 at 3:43 PM, Stephen Hemminger
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.
> Plus there are issues
From: "Luis R. Rodriguez"
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 manual
From: "Luis R. Rodriguez"
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 conf
From: "Luis R. Rodriguez"
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
Cc: bri...@lists.linux-foundation.org
Cc: net..
From: "Luis R. Rodriguez"
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 for t
1 - 100 of 199 matches
Mail list logo
