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 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
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 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 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 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 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 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 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 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 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 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 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 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/
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 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
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/
Cc'ing kvm folks as they may have a shared interest on the shared
physical case with the bridge (non NAT).
On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell wrote:
> On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>>
On Wed, Feb 12, 2014 at 9:17 AM, Bill Fink wrote:
> On Wed, 12 Feb 2014, Ian Campbell wrote:
>> IOW -- enabling/disabling multicast seems to me to be an odd proxy for
>> disabling SLAAC or DAD and AIUI your patch fixes the opposite case,
>> which is to avoid SLAAC and DAD on interfaces which don't
On Wed, Feb 12, 2014 at 3:15 AM, Ian Campbell wrote:
> On Tue, 2014-02-11 at 13:53 -0800, Luis R. Rodriguez wrote:
>> Cc'ing kvm folks as they may have a shared interest on the shared
>> physical case with the bridge (non NAT).
>>
>> On Tue, Feb 11, 2014 at 1
On Wed, Feb 12, 2014 at 2:05 PM, Luis R. Rodriguez
wrote:
> We have to be careful for sure, I'll try to test all cases including
> kvm, but architecturally as I see it so far these things are simply
> exchanging over data through their respective backend channels, I know
> ip
On Wed, Feb 12, 2014 at 8:27 PM, Luis R. Rodriguez
wrote:
> I have a test patch that now works that restricts xen-netback from
> getting any IPv4 and IPv6 addresses, and disables multicast. With this
> set in place the xen-frontend still gets IPv4 and IPv6 addresses and
> Multicast
From: "Luis R. Rodriguez"
It doesn't make sense for some interfaces to become a root bridge
at any point in time. One example is virtual backend interfaces
which rely on other entities on the bridge for actual physical
connectivity. They only provide virtual access.
Device dr
From: "Luis R. Rodriguez"
The xen-netback driver is used only to provide a backend
interface for the frontend. The link is the only thing we
use, and that is used internally for letting us know when the
xen-netfront is ready, when it switches to XenbusStateConnected.
Note that onl
From: "Luis R. Rodriguez"
This v2 series changes the approach from my original virtualization
multicast patch series [0] by abandoning completely the multicast
issues and instead generalizing an approach for virtualization
backends. There are two things in common with virtualizatio
From: "Luis R. Rodriguez"
Some interfaces do not need to have any IPv4 or IPv6
addresses, so enable an option to specify this. One
example where this is observed are virtualization
backend interfaces which just use the net_device
constructs to help with their respective frontends.
T
From: "Luis R. Rodriguez"
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 bridge. This was
possible given that the bridge code will use the lowest MAC
address for a
On Mon, Feb 17, 2014 at 2:27 AM, David Vrabel wrote:
> On 15/02/14 02:59, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>> This v2 series changes the approach from my original virtualization
>> multicast patch series [0] by abandoning completel
On Mon, Feb 17, 2014 at 6:36 AM, Zoltan Kiss wrote:
> There is a valid scenario to put IP addresses on the backend VIFs:
>
> http://wiki.xen.org/wiki/Xen_Networking#Routing
This is useful thanks!
> Also, the backend is not necessarily Dom0, you can connect two guests with
> backend/frontend pair
On Sun, Feb 16, 2014 at 10:57 AM, Stephen Hemminger
wrote:
> On Fri, 14 Feb 2014 18:59:37 -0800
> "Luis R. Rodriguez" wrote:
>
>> From: "Luis R. Rodriguez"
>>
>> It doesn't make sense for some interfaces to become a root bridge
>> at an
On Mon, Feb 17, 2014 at 12:23 PM, Dan Williams wrote:
> On Fri, 2014-02-14 at 18:59 -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>> Some interfaces do not need to have any IPv4 or IPv6
>> addresses, so enable an option to specify this. One
On Tue, Feb 18, 2014 at 3:22 AM, Ian Campbell wrote:
> On Mon, 2014-02-17 at 10:29 +, David Vrabel wrote:
>> On 15/02/14 02:59, Luis R. Rodriguez wrote:
>> > From: "Luis R. Rodriguez"
>> >
>> > The purpose of using a static MAC address of FE:
On Mon, Feb 17, 2014 at 9:52 AM, Zoltan Kiss wrote:
> On 15/02/14 02:59, Luis R. Rodriguez wrote:
>>
>> From: "Luis R. Rodriguez"
>>
>> It doesn't make sense for some interfaces to become a root bridge
>> at any point in time. One example is v
On Wed, Feb 19, 2014 at 6:35 AM, Zoltan Kiss wrote:
> On 19/02/14 09:52, Ian Campbell wrote:
>> Can't we arrange things in the Xen hotplug scripts such that if the
>> root_block stuff isn't available/doesn't work we fallback to the
>> existing fe:ff:ff:ff:ff usage?
>>
>> That would avoid concerns
On Wed, Feb 19, 2014 at 1:48 AM, Ian Campbell wrote:
> On Tue, 2014-02-18 at 11:43 -0800, Luis R. Rodriguez wrote:
>>
>> New motivation: removing IPv4 and IPv6 from the backend interfaces can
>> save up a lot of boiler plate run time code, triggers from ever taking
>>
On Tue, Feb 18, 2014 at 1:42 PM, Stephen Hemminger
wrote:
> On Tue, 18 Feb 2014 13:19:15 -0800
> "Luis R. Rodriguez" wrote:
>
>> Sure, but note that the both disable_ipv6 and accept_dada sysctl
>> parameters are global. ipv4 and ipv6 interfaces are created upon
&g
On Wed, Feb 19, 2014 at 8:45 AM, Dan Williams wrote:
> On Tue, 2014-02-18 at 13:19 -0800, Luis R. Rodriguez wrote:
>> On Mon, Feb 17, 2014 at 12:23 PM, Dan Williams wrote:
>> > On Fri, 2014-02-14 at 18:59 -0800, Luis R. Rodriguez wrote:
>> >> From: "L
On Wed, Feb 19, 2014 at 9:08 AM, Stephen Hemminger
wrote:
> On Wed, 19 Feb 2014 09:02:06 -0800
> "Luis R. Rodriguez" wrote:
>
>> Folks, what if I repurpose my patch to use the IFF_BRIDGE_NON_ROOT (or
>> relabel to IFF_ROOT_BLOCK_DEF) flag for a default driver prefe
On Thu, Feb 20, 2014 at 5:19 AM, Zoltan Kiss wrote:
> How about this: netback sets the root_block flag and a random MAC by
> default. So the default behaviour won't change, DAD will be happy, and
> userspace don't have to do anything unless it's using netback for STP root
> bridge (I don't think t
On Thu, Feb 20, 2014 at 9:19 AM, Stephen Hemminger
wrote:
> On Wed, 19 Feb 2014 09:59:33 -0800 "Luis R. Rodriguez"
> wrote:
>> On Wed, Feb 19, 2014 at 9:08 AM, Stephen Hemminger
>> wrote:
>> >
>> > Please only use the netlink/sysfs flags f
On Thu, Feb 20, 2014 at 6:47 AM, Zoltan Kiss wrote:
> On 19/02/14 16:45, Luis R. Rodriguez wrote:
>
>> You seem to describe a case whereby it can make sense for xen-netback
>> interfaces to end up becoming the root port of a bridge. Can you
>> elaborate a little more on th
On Wed, Feb 19, 2014 at 4:56 PM, Dan Williams wrote:
> Note that there isn't yet a disable_ipv4 knob though, I was
> perhaps-too-subtly trying to get you to send a patch for it, since I can
> use it too :)
Sure, can you describe a little better the use case, as I could use
that for the commit log
On Wed, Feb 19, 2014 at 11:13 AM, Zoltan Kiss wrote:
> On 19/02/14 17:20, Luis R. Rodriguez wrote:
>>>> On 19/02/14 17:20, Luis R. Rodriguez also wrote:
>>>> Zoltan has noted though some use cases of IPv4 or IPv6 addresses on
>>>> backends though <..
On Fri, Feb 21, 2014 at 5:02 AM, Zoltan Kiss wrote:
> On 20/02/14 20:01, Luis R. Rodriguez wrote:
>>
>> On Thu, Feb 20, 2014 at 5:19 AM, Zoltan Kiss
>> wrote:
>>>
>>> How about this: netback sets the root_block flag and a random MAC by
>>> default.
On Fri, Feb 21, 2014 at 5:02 AM, Zoltan Kiss wrote:
>> Agreed that's the best strategy and I'll work on sending patches to
>> brctl to enable the root_block preference. This approach however also
>
> I don't think brctl should deal with any Xen specific stuff. I assume there
> is a misunderstandin
On Fri, Feb 21, 2014 at 8:01 AM, Luis R. Rodriguez
wrote:
> On Fri, Feb 21, 2014 at 5:02 AM, Zoltan Kiss wrote:
>>> Agreed that's the best strategy and I'll work on sending patches to
>>> brctl to enable the root_block preference. This approach however also
>&g
On Fri, Feb 21, 2014 at 5:02 AM, Zoltan Kiss wrote:
> Check this how current Xen scripts does routed networking:
>
> http://wiki.xen.org/wiki/Xen_Networking#Associating_routes_with_virtual_devices
>
> Note, there are no bridges involved here! As the above page says, the
> backend has to have IP ad
On Mon, Feb 24, 2014 at 10:22 AM, Dan Williams wrote:
> My use-case would simply be to have an analogue for the disable_ipv6
> case. In the future I expect more people will want to disable IPv4 as
> they move to IPv6. If you don't have something like disable_ipv4, then
> there's no way to ensure
From: "Luis R. Rodriguez"
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
From: "Luis R. Rodriguez"
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 MAC
a
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"
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
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"
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"
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
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
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 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
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"
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
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
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
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 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 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 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 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 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 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 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, 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 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 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, 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:
>>>>
>>>
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
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
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:
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 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 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
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 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"
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"
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"
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
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
>
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 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 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 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 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 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 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
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
1 - 100 of 132 matches
Mail list logo
