Re: [PATCH v3 REPOST] xen-netfront: delay gARP until backend switches to Connected
From: Ian Campbell Date: Fri, 9 Dec 2011 21:23:00 + > On Fri, 2011-12-09 at 18:45 +, David Miller wrote: >> From: Laszlo Ersek >> Date: Fri, 9 Dec 2011 12:38:58 +0100 >> >> > These two together provide complete ordering. Sub-condition (1) is >> > satisfied by pvops commit 43223efd9bfd. >> >> I don't see this commit in Linus's tree, > > The referenced commit is in > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#xen/next-2.6.32 > some people call the "pvops tree" but there's no reason to expect someone > outside the Xen world to know that... > > A better reference would have been 6b0b80ca7165 in > git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history > which is the precise branch that was flattened to make f942dc2552b8, which > is the upstream commit that added netback, so this change is already in > upstream. I want the commit message fixed so someone seeing the commit ID can figure out what it actually refers to. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 REPOST] xen-netfront: delay gARP until backend switches to Connected
On Fri, 2011-12-09 at 18:45 +, David Miller wrote: > From: Laszlo Ersek > Date: Fri, 9 Dec 2011 12:38:58 +0100 > > > These two together provide complete ordering. Sub-condition (1) is > > satisfied by pvops commit 43223efd9bfd. > > I don't see this commit in Linus's tree, The referenced commit is in git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#xen/next-2.6.32 some people call the "pvops tree" but there's no reason to expect someone outside the Xen world to know that... A better reference would have been 6b0b80ca7165 in git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history which is the precise branch that was flattened to make f942dc2552b8, which is the upstream commit that added netback, so this change is already in upstream. Ian. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 REPOST] xen-netfront: delay gARP until backend switches to Connected
From: Laszlo Ersek Date: Fri, 9 Dec 2011 12:38:58 +0100 > These two together provide complete ordering. Sub-condition (1) is > satisfied by pvops commit 43223efd9bfd. I don't see this commit in Linus's tree, so I doubt it's valid for me to apply this as a bug fix to my 'net' tree since the precondition pvops commit isn't upstream as far as I can tell. Where did you intend me to apply this patch, and how did you expect the dependent commit to make it's way into the tree so that this fix is complete? BTW, you should always explicitly specificy the answers to all the questions in the previous paragraph, otherwise (like right now) we go back and forth wasting time establishing these facts. The way to say which tree the patch is intended for is to specify it in the Subject like, f.e. "[PATCH net-next v3 REPOST] ..." ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v3 REPOST] xen-netfront: delay gARP until backend switches to Connected
After a guest is live migrated, the xen-netfront driver emits a gratuitous ARP message, so that networking hardware on the target host's subnet can take notice, and public routing to the guest is re-established. However, if the packet appears on the backend interface before the backend is added to the target host's bridge, the packet is lost, and the migrated guest's peers become unable to talk to the guest. A sufficient two-parts condition to prevent the above is: (1) ensure that the backend only moves to Connected xenbus state after its hotplug scripts completed, ie. the netback interface got added to the bridge; and (2) ensure the frontend only queues the gARP when it sees the backend move to Connected. These two together provide complete ordering. Sub-condition (1) is satisfied by pvops commit 43223efd9bfd. In general, the full condition is sufficient, not necessary, because, according to [1], live migration has been working for a long time without satisfying sub-condition (2). However, after 43223efd9bfd was backported to the RHEL-5 host to ensure (1), (2) still proved necessary in the RHEL-6 guest. This patch intends to provide (2) for upstream. The Reviewed-by line comes from [2]. [1] http://old-list-archives.xen.org/xen-devel/2011-06/msg01969.html [2] http://old-list-archives.xen.org/xen-devel/2011-07/msg00484.html Signed-off-by: Laszlo Ersek Reviewed-by: Ian Campbell --- drivers/net/xen-netfront.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index d29365a..f033656 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -1646,7 +1646,6 @@ static void netback_changed(struct xenbus_device *dev, case XenbusStateInitialised: case XenbusStateReconfiguring: case XenbusStateReconfigured: - case XenbusStateConnected: case XenbusStateUnknown: case XenbusStateClosed: break; @@ -1657,6 +1656,9 @@ static void netback_changed(struct xenbus_device *dev, if (xennet_connect(netdev) != 0) break; xenbus_switch_state(dev, XenbusStateConnected); + break; + + case XenbusStateConnected: netif_notify_peers(netdev); break; -- 1.7.4.4 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
On 12/08/2011 03:10 PM, Avi Kivity wrote: On 12/07/2011 06:46 PM, Raghavendra K T wrote: On 12/07/2011 08:22 PM, Avi Kivity wrote: On 12/07/2011 03:39 PM, Marcelo Tosatti wrote: Also I think we can keep the kicked flag in vcpu->requests, no need for new storage. Was going to suggest it but it violates the currently organized processing of entries at the beginning of vcpu_enter_guest. That is, this "kicked" flag is different enough from vcpu->requests processing that a separate variable seems worthwhile (even more different with convertion to MP_STATE at KVM_GET_MP_STATE). IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to change due to apic re-evaluation). Ok, So what I understand is we have to either : 1. retain current kick flag AS-IS but would have to make it migration friendly. [I still have to get more familiar with migration side] or 2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of vcpu->requests. So what would be better? Please let me know. IMO, KVM_REQ. Ok, 'll continue in this direction. Hmm I think now the race condition should be kept in mind, pointed by Marcello. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/11] RFC: PCI using capabilitities
On Thu, 08 Dec 2011 17:37:37 +0200, Sasha Levin wrote: > Which leads me to the question: Are MMIO vs MMIO reads/writes not > ordered? That seems really odd, especially being repeatable. BTW, that's an address, not a pfn now. Cheers, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [net-next RFC PATCH 0/5] Series short description
On Wed, 7 Dec 2011 17:02:04 +, Ben Hutchings wrote: > Solarflare controllers (sfc driver) have 8192 perfect filters for > TCP/IPv4 and UDP/IPv4 which can be used for flow steering. (The filters > are organised as a hash table, but matched based on 5-tuples.) I > implemented the 'accelerated RFS' interface in this driver. > > I believe the Intel 82599 controllers (ixgbe driver) have both > hash-based and perfect filter modes and the driver can be configured to > use one or the other. The driver has its own independent mechanism for > steering RX and TX flows which predates RFS; I don't know whether it > uses hash-based or perfect filters. Thanks for this summary (and Jason, too). I've fallen a long way behind NIC state-of-the-art. > Most multi-queue controllers could support a kind of hash-based > filtering for TCP/IP by adjusting the RSS indirection table. However, > this table is usually quite small (64-256 entries). This means that > hash collisions will be quite common and this can result in reordering. > The same applies to the small table Jason has proposed for virtio-net. But this happens on real hardware today. Better that real hardware is nice, but is it overkill? And can't you reorder even with perfect matching, since prior packets will be on the old queue and more recent ones on the new queue? Does it discard or requeue old ones? Or am I missing a trick? Thanks, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
On Thu, 08 Dec 2011 12:37:48 +0200, Sasha Levin wrote: > On Thu, 2011-12-08 at 20:14 +1030, Rusty Russell wrote: > > On Wed, 7 Dec 2011 17:48:17 +0200, "Michael S. Tsirkin" > > wrote: > > > On Wed, Dec 07, 2011 at 04:02:45PM +0200, Sasha Levin wrote: > > > > On Sun, 2011-12-04 at 20:23 +0200, Sasha Levin wrote: > > > > > > > > [snip] > > > > > > > > Rusty, Michael, does the below looks a reasonable optimization for you? > > > > > > OK overall but a bit hard to say for sure as it looks pretty incomplete > > > ... > > > > A static threshold is very hackish; we need to either initialize it to > > a proven-good value (since noone will ever change it) or be cleverer. > > I'll better wait to see how the threshold issue is resolved, and > possibly do it as a dynamic value which depends on the threshold. > > I doubt theres one magic value which would work for all. Sure, but if it's generally better than the current value, I'll apply it. Cheers, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
