Re: [Xen-devel] [PATCH] xen-netfront, xen-netback: Use correct minimum MTU values

[David Miller]

From: Boris Ostrovsky 
Date: Mon, 16 Oct 2017 16:19:07 -0400

> On 10/16/2017 11:05 AM, Wei Liu wrote:
>> On Mon, Oct 16, 2017 at 03:20:32PM +0200, Mohammed Gamal wrote:
>>> RFC791 specifies the minimum MTU to be 68, while xen-net{front|back}
>>> drivers use a minimum value of 0.
>>>
>>> When set MTU to 0~67 with xen_net{front|back} driver, the network
>>> will become unreachable immediately, the guest can no longer be pinged.
>>>
>>> xen_net{front|back} should not allow the user to set this value which causes
>>> network problems.
>>>
>>> Reported-by: Chen Shi 
>>> Signed-off-by: Mohammed Gamal 
>> Acked-by: Wei Liu 
>>
>> CC netfront maintainers
> 
> 
> Reviewed-by: Boris Ostrovsky 
> 
> I can take it via Xen tree unless there are objections.

No problem on my end.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net] xen-netback: correctly schedule rate-limited queues

[David Miller]

From: Jean-Louis Dupond <jean-lo...@dupond.be>
Date: Thu, 27 Jul 2017 10:21:56 +0200

> Op 2017-06-22 17:16, schreef David Miller:
>> From: Wei Liu <wei.l...@citrix.com>
>> Date: Wed, 21 Jun 2017 10:21:22 +0100
>> 
>>> Add a flag to indicate if a queue is rate-limited. Test the flag in
>>> NAPI poll handler and avoid rescheduling the queue if true, otherwise
>>> we risk locking up the host. The rescheduling will be done in the
>>> timer callback function.
>>> Reported-by: Jean-Louis Dupond <jean-lo...@dupond.be>
>>> Signed-off-by: Wei Liu <wei.l...@citrix.com>
>>> Tested-by: Jean-Louis Dupond <jean-lo...@dupond.be>
>> Applied.
> 
> Could this get applied to stable & LTS kernels also?
> Seems important enough in my opinion.

Sure, queued up.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net] xen-netback: correctly schedule rate-limited queues

[David Miller]

From: Wei Liu 
Date: Wed, 21 Jun 2017 10:21:22 +0100

> Add a flag to indicate if a queue is rate-limited. Test the flag in
> NAPI poll handler and avoid rescheduling the queue if true, otherwise
> we risk locking up the host. The rescheduling will be done in the
> timer callback function.
> 
> Reported-by: Jean-Louis Dupond 
> Signed-off-by: Wei Liu 
> Tested-by: Jean-Louis Dupond 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 20/44] sparc: implement ->mapping_error

[David Miller]

From: Christoph Hellwig 
Date: Thu,  8 Jun 2017 15:25:45 +0200

> DMA_ERROR_CODE is going to go away, so don't rely on it.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 28/44] sparc: remove arch specific dma_supported implementations

[David Miller]

From: Christoph Hellwig 
Date: Thu,  8 Jun 2017 15:25:53 +0200

> Usually dma_supported decisions are done by the dma_map_ops instance.
> Switch sparc to that model by providing a ->dma_supported instance for
> sbus that always returns false, and implementations tailored to the sun4u
> and sun4v cases for sparc64, and leave it unimplemented for PCI on
> sparc32, which means always supported.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 27/44] sparc: remove leon_dma_ops

[David Miller]

From: Christoph Hellwig 
Date: Thu,  8 Jun 2017 15:25:52 +0200

> We can just use pci32_dma_ops.
> 
> Btw, given that leon is 32-bit and appears to be PCI based, do even need
> the special case for it in get_arch_dma_ops at all?

I would need to defer to the LEON developers on that, but they haven't
been very actively lately so whether you'll get a response or not is
hard to predict.

> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] clean up and modularize arch dma_mapping interface

[David Miller]

From: Christoph Hellwig 
Date: Thu,  8 Jun 2017 15:25:25 +0200

> for a while we have a generic implementation of the dma mapping routines
> that call into per-arch or per-device operations.  But right now there
> still are various bits in the interfaces where don't clearly operate
> on these ops.  This series tries to clean up a lot of those (but not all
> yet, but the series is big enough).  It gets rid of the DMA_ERROR_CODE
> way of signaling failures of the mapping routines from the
> implementations to the generic code (and cleans up various drivers that
> were incorrectly using it), and gets rid of the ->set_dma_mask routine
> in favor of relying on the ->dma_capable method that can be used in
> the same way, but which requires less code duplication.

There is unlikely to be conflicts for the sparc and net changes, so I
will simply ACK them.

Thanks Christoph.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 02/44] ibmveth: properly unwind on init errors

[David Miller]

From: Christoph Hellwig 
Date: Thu,  8 Jun 2017 15:25:27 +0200

> That way the driver doesn't have to rely on DMA_ERROR_CODE, which
> is not a public API and going away.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David S. Miller 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen-netfront: avoid crashing on resume after a failure in talk_to_netback()

[David Miller]

From: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: Thu, 11 May 2017 13:58:06 +0200

> Unavoidable crashes in netfront_resume() and netback_changed() after a
> previous fail in talk_to_netback() (e.g. when we fail to read MAC from
> xenstore) were discovered. The failure path in talk_to_netback() does
> unregister/free for netdev but we don't reset drvdata and we try accessing
> it after resume.
> 
> Fix the bug by removing the whole xen device completely with
> device_unregister(), this guarantees we won't have any calls into netfront
> after a failure.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
> ---
> Changes since v1: instead of cleaning drvdata and checking for it in
> netfront_resume() and netback_changed() remove the device completely with
> device_unregister() [David Miller]

This looks a lot better, applied, thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netfront: avoid crashing on resume after a failure in talk_to_netback()

[David Miller]

From: Vitaly Kuznetsov 
Date: Thu,  4 May 2017 14:23:04 +0200

> Unavoidable crashes in netfront_resume() and netback_changed() after a
> previous fail in talk_to_netback() (e.g. when we fail to read MAC from
> xenstore) were discovered. The failure path in talk_to_netback() does
> unregister/free for netdev but we don't reset drvdata and we try accessing
> it again after resume.
> 
> Reset drvdata in netback_changed() the same way we reset it in
> netfront_probe() and check for NULL in both netfront_resume() and
> netback_changed() to properly handle the situation.
> 
> Signed-off-by: Vitaly Kuznetsov 

The circumstances under which netfront_probe() NULLs out the device
private is different than what you propose here, which is to do it
on a live device in netback_changed() whilst mutliple susbsytems
have a reference to this device and can call into the driver still.

It is only legal to do this in the probe function because such
references and execution possibilities do not exist at that point.

What really needs to happen is that the xenbus_driver must be told to
unregister this xen device and stop making calls into the driver for
it before you release the netdev state.

That is the only reasonable way to fix this bug.

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net v4] xen-netback: fix race condition on XenBus disconnect

[David Miller]

From: Igor Druzhinin 
Date: Fri, 10 Mar 2017 21:36:22 +

> In some cases during XenBus disconnect event handling and subsequent
> queue resource release there may be some TX handlers active on
> other processors. Use RCU in order to synchronize with them.
> 
> Signed-off-by: Igor Druzhinin 

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net 0/2] xen-netback: update memory leak fix to avoid BUG

[David Miller]

From: Paul Durrant 
Date: Thu, 2 Mar 2017 12:54:24 +

> Commit 9a6cdf52b85e "xen-netback: fix memory leaks on XenBus disconnect"
> added missing code to fix a memory leak by calling vfree() in the
> appropriate place.
> Unfortunately subsequent commit f16f1df65f1c "xen-netback: protect
> resource cleaning on XenBus disconnect" then wrapped this call to vfree()
> in a spin lock, leading to a BUG due to incorrect context.
> 
> Patch #1 makes the existing code more readable
> Patch #2 fixes the problem

Series applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net] xen-netback: Use GFP_ATOMIC to allocate hash

[David Miller]

From: Anoob Soman 
Date: Thu, 2 Mar 2017 10:50:20 +

> Allocation of new_hash, inside xenvif_new_hash(), always happen
> in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new
> hash allocation.
> 
> Signed-off-by: Anoob Soman 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[David Miller]

From: Boris Ostrovsky 
Date: Thu, 9 Feb 2017 08:42:59 -0500

> Are you going to take this to your tree or would you rather it goes
> via Xen tree?

Ok, I just did.

> And the same question for
> 
> https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00625.html

As I stated in the thread, I applied this one.

> https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00754.html

Likewise.

In the future, if you use netdev patchwork URLs, two things will
happen.  You will see immediately in the discussion log and the patch
state whether I applied it or not.  And second, I will be able to
reference and do something with the patch that much more quickly
and easily.

Thank you.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] xen-netfront: Improve error handling during initialization

[David Miller]

From: Ross Lagerwall 
Date: Wed, 8 Feb 2017 10:57:37 +

> This fixes a crash when running out of grant refs when creating many
> queues across many netdevs.
> 
> * If creating queues fails (i.e. there are no grant refs available),
> call xenbus_dev_fatal() to ensure that the xenbus device is set to the
> closed state.
> * If no queues are created, don't call xennet_disconnect_backend as
> netdev->real_num_tx_queues will not have been set correctly.
> * If setup_netfront() fails, ensure that all the queues created are
> cleaned up, not just those that have been set up.
> * If any queues were set up and an error occurs, call
> xennet_destroy_queues() to clean up the napi context.
> * If any fatal error occurs, unregister and destroy the netdev to avoid
> leaving around a half setup network device.
> 
> Signed-off-by: Ross Lagerwall 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netfront: Rework the fix for Rx stall during OOM and network stress

[David Miller]

From: Vineeth Remanan Pillai 
Date: Tue, 7 Feb 2017 18:59:01 +

> The commit 90c311b0eeea ("xen-netfront: Fix Rx stall during network
> stress and OOM") caused the refill timer to be triggerred almost on
> all invocations of xennet_alloc_rx_buffers for certain workloads.
> This reworks the fix by reverting to the old behaviour and taking into
> consideration the skb allocation failure. Refill timer is now triggered
> on insufficient requests or skb allocation failure.
> 
> Signed-off-by: Vineeth Remanan Pillai 
> Fixes: 90c311b0eeea (xen-netfront: Fix Rx stall during network stress and OOM)
> Reported-by: Boris Ostrovsky 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netfront: Improve error handling during initialization

[David Miller]

From: Ross Lagerwall 
Date: Wed, 1 Feb 2017 15:50:22 +

> * Delay timer creation so that if initializing a queue fails, the timer
> has not been setup yet.

setup_timer() doesn't do anything that must be "undone" if an error
occurs and we have to cleanup.

It just assigns some values to some timer struct fields, that's it.

Therefore this change is extraneous and unnecessary.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xennet_start_xmit assumptions

[David Miller]

From: Sowmini Varadhan 
Date: Thu, 19 Jan 2017 17:41:23 -0500

> On (01/19/17 13:47), Sowmini Varadhan wrote:
>> > Specifically I'm talking about the dev_validate_header() check.
>> > That is supposed to protect us from these kinds of situations.
>> 
>> ah, but I run my pf_packet application as root, so I have 
>> capable(CAP_SYS_RAWIO), so I slip through the dev_validate_header()
>> check.
> 
> and in that light, should dev_validate_header()
> always return false if len == 0?
> 
> that will take care of all the send paths in af_packet.c
> but it impacts all drivers as well (even though it is the
> logically correct thing to do..)

I think dev_validate_header() almost does the correct thing in
the SYS_RAWIO case.

It clears out the not-provided hard header bytes, but it doesn't
adjust the skb->len.  I think that is a real requirement in this
situation.

CAP_SYS_RAWIO or not, the contract we have with the device is that
there will be at least enough bytes to cover a link layer header.

This probably requires a little bit of an adjustment to the calling
convention.  Perhaps:

int dev_validate_header(const struct net_device *dev,
char *ll_header, int len);

So then you can go:

new_len = dev_validate_header(dev, skb->data, len);
if (new_len < 0)
goto out_cleanup_err;
if (new_len > len)
__skb_put(skb, new_len - len);

Or something like that.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xennet_start_xmit assumptions

[David Miller]

From: Sowmini Varadhan 
Date: Thu, 19 Jan 2017 06:14:26 -0500

> I'll probably work on fixing packet_snd to return -EINVAL 
> or similar when the len is zero this week.

I thought we had code which made sure that at least a minimal
link layer header was present in the SKB?

Specifically I'm talking about the dev_validate_header() check.
That is supposed to protect us from these kinds of situations.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/2] xen-netback: fix memory leaks on XenBus disconnect

[David Miller]

From: Igor Druzhinin 
Date: Tue, 17 Jan 2017 20:49:36 +

> Just split the initial patch in two as proposed by Wei.
> 
> Since the approach for locking netdev statistics is inconsistent (tends not
> to have any locking at all) accross the kernel we'd better to rely on our
> internal lock for this purpose.

Series applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

This v2 never made it into patchwork.  I don't know why, so please resend it to
netdev with the accumulated reviewed-by etc. tags added.

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

From: Vineeth Remanan Pillai 
Date: Wed, 18 Jan 2017 09:02:17 -0800

> 
> On 01/15/2017 10:24 PM, Juergen Gross wrote:
>> On 13/01/17 18:55, Remanan Pillai wrote:
>>> From: Vineeth Remanan Pillai 
>>>
>>> During an OOM scenario, request slots could not be created as skb
>>> allocation fails. So the netback cannot pass in packets and netfront
>>> wrongly assumes that there is no more work to be done and it disables
>>> polling. This causes Rx to stall.
>>>
>>> The issue is with the retry logic which schedules the timer if the
>>> created slots are less than NET_RX_SLOTS_MIN. The count of new request
>>> slots to be pushed are calculated as a difference between new req_prod
>>> and rsp_cons which could be more than the actual slots, if there are
>>> unconsumed responses.
>>>
>>> The fix is to calculate the count of newly created slots as the
>>> difference between new req_prod and old req_prod.
>>>
>>> Signed-off-by: Vineeth Remanan Pillai 
>> Reviewed-by: Juergen Gross 
> Thanks Juergen.
> 
> David,
> 
> Could you please pick up this change for net-next if there no more
> concerns..

Why would I pick up "this change", if the author of the patch has
stated that he will resubmit the change implemented differently based
upon my feedback?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

From: Vineeth Remanan Pillai 
Date: Wed, 11 Jan 2017 23:17:17 +

> @@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int 
> budget)
>   napi_complete(napi);
>  
>   RING_FINAL_CHECK_FOR_RESPONSES(>rx, more_to_do);
> - if (more_to_do)
> +
> + /* If there is more work to do or could not allocate
> +  * rx buffers, re-enable polling.
> +  */
> + if (more_to_do || err != 0)
>   napi_schedule(napi);

Just polling endlessly in a loop retrying the SKB allocation over and over
again until it succeeds is not very nice behavior.

You already have that refill timer, so please use that to retry instead
of wasting cpu cycles looping in NAPI poll.

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] uapi: use wildcards to list files

[David Miller]

From: Nicolas Dichtel 
Date: Tue,  3 Jan 2017 15:35:44 +0100

> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
> 
> In fact, all headers under include/uapi/ should be exported, so let's
> use wildcards.
> 
> After this patch, the following files, which were not exported, are now
> exported:
 ...
> 
> Signed-off-by: Nicolas Dichtel 

Acked-by: David S. Miller 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Xen PATCH] xen-netback: fix error handling output

[David Miller]

From: Arnd Bergmann 
Date: Tue,  8 Nov 2016 14:34:34 +0100

> The connect function prints an unintialized error code after an
> earlier initialization was removed:
> 
> drivers/net/xen-netback/xenbus.c: In function 'connect':
> drivers/net/xen-netback/xenbus.c:938:3: error: 'err' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This prints it as -EINVAL instead, which seems to be the most
> appropriate error code. Before the patch that caused the warning,
> this would print a positive number returned by vsscanf() instead,
> which is also wrong. We probably don't need a backport though,
> as fixing the warning here should be sufficient.
> 
> Fixes: f95842e7a9f2 ("xen: make use of xenbus_read_unsigned() in xen-netback")
> Fixes: 8d3d53b3e433 ("xen-netback: Add support for multiple queues")
> Signed-off-by: Arnd Bergmann 

That first Fixes: commit mentioned is in neither of my trees, so I
assume it is in the Xen tree and thus this fix should get applied
there.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] xen-netback: prefer xenbus_scanf() over xenbus_gather()

[David Miller]

From: "Jan Beulich" 
Date: Tue, 08 Nov 2016 00:45:53 -0700

> For single items being collected this should be preferred as being more
> typesafe (as the compiler can check format string and to-be-written-to
> variable match) and more efficient (requiring one less parameter to be
> passed).
> 
> Signed-off-by: Jan Beulich 
> ---
> v3: For consistency with other code don't consider zero an error
> (utilizing that xenbus_scanf() at present won't return zero).
> v2: Avoid commit message to continue from subject.

Applied to net-next, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/1] xen-netfront: cast grant table reference first to type int

[David Miller]

From: Dongli Zhang 
Date: Wed,  2 Nov 2016 09:04:33 +0800

> IS_ERR_VALUE() in commit 87557efc27f6a50140fb20df06a917f368ce3c66
> ("xen-netfront: do not cast grant table reference to signed short") would
> not return true for error code unless we cast ref first to type int.
> 
> Signed-off-by: Dongli Zhang 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

[David Miller]

From: Dongli Zhang 
Date: Mon, 31 Oct 2016 21:46:09 -0700 (PDT)

> David, I am very sorry for this error and I will be careful the next time.
> Would you please let me know if I should resend a new patch or an incremental
> based on previous one at 
> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git?

Incremental, please.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

[David Miller]

From: Dongli Zhang 
Date: Mon, 31 Oct 2016 13:38:29 +0800

> While grant reference is of type uint32_t, xen-netfront erroneously casts
> it to signed short in BUG_ON().
> 
> This would lead to the xen domU panic during boot-up or migration when it
> is attached with lots of paravirtual devices.
> 
> Signed-off-by: Dongli Zhang 

Since this is consistent with how the macros in linux/err.h handle "is
this an error" checks, this change looks good to me.

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen: add common function for reading optional value

[David Miller]

From: Juergen Gross 
Date: Mon, 31 Oct 2016 17:48:18 +0100

> There are multiple instances of code reading an optional unsigned
> parameter from Xenstore via xenbus_scanf(). Instead of repeating the
> same code over and over add a service function doing the job and
> replace the call of xenbus_scanf() with the call of the new function
> where appropriate.

As this seems to be a series that will go through some tree other
than mine, I assume the networking bits will be taken care of that
way.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH/RFC 0/5] cpu_relax: introduce yield, remove lowlatency

[David Miller]

From: Christian Borntraeger <borntrae...@de.ibm.com>
Date: Fri, 21 Oct 2016 17:08:54 +0200

> On 10/21/2016 04:57 PM, David Miller wrote:
>> From: Christian Borntraeger <borntrae...@de.ibm.com>
>> Date: Fri, 21 Oct 2016 13:58:53 +0200
>> 
>>> For spinning loops people did often use barrier() or cpu_relax().
>>> For most architectures cpu_relax and barrier are the same, but on
>>> some architectures cpu_relax can add some latency. For example on s390
>>> cpu_relax gives up the time slice to the hypervisor. On power cpu_relax
>>> tries to give some of the CPU to the neighbor threads. To reduce the
>>> latency another variant cpu_relax_lowlatency was introduced. Before this
>>> is used in more and more places, lets revert the logic of provide a new
>>> function cpu_relax_yield that can spend some time and for s390 yields
>>> the guest CPU.
>> 
>> Sparc64, fwiw, behaves similarly to powerpc.
> 
> As sparc currently defines cpu_relax_lowlatency to cpu_relax, this patch set
> should be a no-op then for sparc, correct?
> 
> My intend was that cpu_relax should not add a huge latency but can certainly
> push some cpu power to hardware threads of the same core. This seems to be
> the case for sparc/power and some arc variants. 

Agreed.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netback: fix type mismatch warning

[David Miller]

From: Arnd Bergmann 
Date: Wed, 12 Oct 2016 16:54:01 +0200

> Wiht the latest rework of the xen-netback driver, we get a warning
> on ARM about the types passed into min():
> 
> drivers/net/xen-netback/rx.c: In function 'xenvif_rx_next_chunk':
> include/linux/kernel.h:739:16: error: comparison of distinct pointer types 
> lacks a cast [-Werror]
> 
> The reason is that XEN_PAGE_SIZE is not size_t here. There
> is no actual bug, and we can easily avoid the warning using the
> min_t() macro instead of min().
> 
> Fixes: eb1723a29b9a ("xen-netback: refactor guest rx")
> Signed-off-by: Arnd Bergmann 

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 net] xen-netback: fix guest Rx stall detection (after guest Rx refactor)

[David Miller]

From: David Vrabel 
Date: Tue, 11 Oct 2016 16:48:27 +0100

> If a VIF has been ready for rx_stall_timeout (60s by default) and an
> Rx ring is drained of all requests an Rx stall will be incorrectly
> detected.  When this occurs and the guest Rx queue is empty, the Rx
> ring's event index will not be set and the frontend will not raise an
> event when new requests are placed on the ring, permanently stalling
> the VIF.
> 
> This is a regression introduced by eb1723a29b9a7 (xen-netback:
> refactor guest rx).
> 
> Fix this by reinstating the setting of queue->last_rx_time when
> placing a packet onto the guest Rx ring.
> 
> Signed-off-by: David Vrabel 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net] xen-netback: (re-)create a debugfs node for hash information

[David Miller]

From: Paul Durrant 
Date: Mon, 10 Oct 2016 09:30:53 +0100

> From: Paul Durrant 
> 
> It is useful to be able to see the hash configuration when running tests.
> This patch adds a debugfs node for that purpose.
> 
> The original version of this patch (commit c0c64c152389) was reverted due
> to build failures caused by a conflict with commit 0364a8824c02
> ("xen-netback: switch to threaded irq for control ring"). This new version
> of the patch is nearly identical to the original, the only difference
> being that creation of the debugfs node is predicated on 'ctrl_irq' being
> non-zero rather then the now non-existent 'ctrl_task'.
> 
> Signed-off-by: Paul Durrant 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next] MAINTAINERS: add myself as a maintainer of xen-netback

[David Miller]

From: Paul Durrant 
Date: Fri, 7 Oct 2016 11:33:37 +0100

> Signed-off-by: Paul Durrant 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net] xen-netback: make sure that hashes are not send to unaware frontends

[David Miller]

From: Paul Durrant 
Date: Thu, 6 Oct 2016 15:47:10 +0100

> In the case when a frontend only negotiates a single queue with xen-
> netback it is possible for a skbuff with a s/w hash to result in a
> hash extra_info segment being sent to the frontend even when no hash
> algorithm has been configured. (The ndo_select_queue() entry point makes
> sure the hash is not set if no algorithm is configured, but this entry
> point is not called when there is only a single queue). This can result
> in a frontend that isunable to handle extra_info segments being given
> such a segment, causing it to crash.
> 
> This patch fixes the problem by gating whether the extra_info is sent
> not only on the presence of a s/w hash, but also on whether the hash
> algorithm has been configured.
> 
> Signed-off-by: Paul Durrant 
> Cc: Wei Liu 

This doesn't apply cleanly to the current 'net' tree, please respin.

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 net-next 0/7] xen-netback: guest rx side refactor

[David Miller]

From: Paul Durrant 
Date: Tue, 4 Oct 2016 10:29:11 +0100

> This series refactors the guest rx side of xen-netback:
> 
> - The code is moved into its own source module.
> 
> - The prefix variant of GSO handling is retired (since it is no longer
>   in common use, and alternatives exist).
> 
> - The code is then simplified and modifications made to improve
>   performance.
> 
> v2:
> - Rebased onto refreshed net-next

Series applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next 0/7] xen-netback: guest rx side refactor

[David Miller]

From: Paul Durrant 
Date: Mon, 3 Oct 2016 08:31:05 +0100

> This series refactors the guest rx side of xen-netback:
> 
> - The code is moved into its own source module.
> 
> - The prefix variant of GSO handling is retired (since it is no longer
>   in common use, and alternatives exist).
> 
> - The code is then simplified and modifications made to improve
>   performance.

This doesn't apply cleanly to net-next, please respin.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH resend 2] xen-netback: switch to threaded irq for control ring

[David Miller]

From: Juergen Gross 
Date: Thu, 22 Sep 2016 11:06:25 +0200

> Instead of open coding it use the threaded irq mechanism in
> xen-netback.
> 
> Signed-off-by: Juergen Gross 

Applied to net-next, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v3] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Miller]

From: Vitaly Kuznetsov 
Date: Mon, 19 Sep 2016 12:53:40 +0200

> Small packet loss is reported on complex multi host network configurations
> including tunnels, NAT, ... My investigation led me to the following check
> in netback which drops packets:
> 
> if (unlikely(txreq.size < ETH_HLEN)) {
> netdev_err(queue->vif->dev,
>"Bad packet size: %d\n", txreq.size);
> xenvif_tx_err(queue, , extra_count, idx);
> break;
> }
> 
> But this check itself is legitimate. SKBs consist of a linear part (which
> has to have the ethernet header) and (optionally) a number of frags.
> Netfront transmits the head of the linear part up to the page boundary
> as the first request and all the rest becomes frags so when we're
> reconstructing the SKB in netback we can't distinguish between original
> frags and the 'tail' of the linear part. The first SKB needs to be at
> least ETH_HLEN size. So in case we have an SKB with its linear part
> starting too close to the page boundary the packet is lost.
> 
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
>   the original SKB structure. We'll have to add a flag indicating the fact
>   that the particular request is a part of the original linear part and not
>   a frag. We'll need to know the length of the linear part to pre-allocate
>   memory.
> - Avoid transmitting SKBs with linear parts starting too close to the page
>   boundary. That seems preferable short-term and shouldn't bring
>   significant performance degradation as such packets are rare. That's what
>   this patch is trying to achieve with skb_copy().
> 
> Signed-off-by: Vitaly Kuznetsov 
> Acked-by: David Vrabel 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next RESEND] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Miller]

From: Vitaly Kuznetsov 
Date: Fri, 16 Sep 2016 12:59:14 +0200

> @@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb, struct 
> net_device *dev)
>   offset = offset_in_page(skb->data);
>   len = skb_headlen(skb);
>  
> + /* The first req should be at least ETH_HLEN size or the packet will be
> +  * dropped by netback.
> +  */
> + if (unlikely(PAGE_SIZE - offset < ETH_HLEN)) {
> + nskb = skb_copy(skb, GFP_ATOMIC);
> + if (!nskb)
> + goto drop;
> + dev_kfree_skb_any(skb);
> + skb = nskb;
> + page = virt_to_page(skb->data);
> + offset = offset_in_page(skb->data);
> + }
> +
>   spin_lock_irqsave(>tx_lock, flags);

I think you also have to recalculate 'len' in this case too, as
skb_headlen() will definitely be different for nskb.

In fact, I can't see how this code can work properly without that fix.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen-netback: fix error handling on netback_probe()

[David Miller]

From: Filipe Manco 
Date: Thu, 15 Sep 2016 17:10:46 +0200

> In case of error during netback_probe() (e.g. an entry missing on the
> xenstore) netback_remove() is called on the new device, which will set
> the device backend state to XenbusStateClosed by calling
> set_backend_state(). However, the backend state wasn't initialized by
> netback_probe() at this point, which will cause and invalid transaction
> and set_backend_state() to BUG().
> 
> Initialize the backend state at the beginning of netback_probe() to
> XenbusStateInitialising, and create two new valid state transitions on
> set_backend_state(), from XenbusStateInitialising to XenbusStateClosed,
> and from XenbusStateInitialising to XenbusStateInitWait.
> 
> Signed-off-by: Filipe Manco 

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH -next] xen-netback: using kfree_rcu() to simplify the code

[David Miller]

From: Wei Yongjun 
Date: Mon, 22 Aug 2016 23:01:29 +

> From: Wei Yongjun 
> 
> The callback function of call_rcu() just calls a kfree(), so we
> can use kfree_rcu() instead of call_rcu() + callback function.
> 
> Signed-off-by: Wei Yongjun 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next] xen-netback: create a debugfs node for hash information

[David Miller]

From: Paul Durrant 
Date: Wed, 17 Aug 2016 16:13:29 +0100

> It is useful to be able to see the hash configuration when running tests.
> This patch adds a debugfs node for that purpose.
> 
> Signed-off-by: Paul Durrant 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next] xen-netback: only deinitialized hash if it was initialized

[David Miller]

From: Paul Durrant 
Date: Wed, 18 May 2016 15:55:42 +0100

> A domain with a frontend that does not implement a control ring has been
> seen to cause a crash during domain save. This was apparently because
> the call to xenvif_deinit_hash() in xenvif_disconnect_ctrl() is made
> regardless of whether a control ring was connected, and hence
> xenvif_hash_init() was called.
> 
> This patch brings the call to xenvif_deinit_hash() in
> xenvif_disconnect_ctrl() inside the if clause that checks whether the
> control ring event channel was connected. This is sufficient to ensure
> it is only called if xenvif_init_hash() was called previously.
> 
> Signed-off-by: Paul Durrant 
> Reported-by: Boris Ostrovsky 
> Tested-by: Boris Ostrovsky 

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next] xen-netback: correct length checks on hash copy_ops

[David Miller]

From: Paul Durrant 
Date: Wed, 18 May 2016 08:53:01 +0100

> The length checks on the grant table copy_ops for setting hash key and
> hash mapping are checking the local 'len' value which is correct in
> the case of the former but not the latter. This was picked up by
> static analysis checks.
> 
> This patch replaces checks of 'len' with 'copy_op.len' in both cases
> to correct the incorrect check, keep the two checks consistent, and to
> make it clear what the checks are for.
> 
> Signed-off-by: Paul Durrant 
> Reported-by: Dan Carpenter 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v4 0/4] xen-netback: support for control ring

[David Miller]

From: Paul Durrant 
Date: Fri, 13 May 2016 09:37:25 +0100

> My recent patch to import an up-to-date include/xen/interface/io/netif.h
> from the Xen Project brought in the necessary definitions to support the
> new control shared ring and protocol. This patch series updates xen-netback
> to support the new ring.
> 
> Patch #1 adds the necessary boilerplate to map the control ring and handle
> messages. No implementation of the new protocol is included in this patch
> so that it can be kept to a reasonable size.
> 
> Patch #2 adds the protocol implementation.
> 
> Patch #3 adds support for passing has values calculated by xen-netback to
> capable frontends.
> 
> Patch #4 adds support for accepting hash values calculated by capable
> frontends and using them the set the socket buffer hash.

Series applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net] xen-netback: fix extra_info handling in xenvif_tx_err()

[David Miller]

From: Paul Durrant 
Date: Thu, 12 May 2016 14:43:03 +0100

> Patch 562abd39 "xen-netback: support multiple extra info fragments
> passed from frontend" contained a mistake which can result in an in-
> correct number of responses being generated when handling errors
> encountered when processing packets containing extra info fragments.
> This patch fixes the problem.
> 
> Signed-off-by: Paul Durrant 
> Reported-by: Jan Beulich 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for control ring

[David Miller]

From: Paul Durrant 
Date: Wed, 11 May 2016 16:16:26 +0100

> My recent patch to import an up-to-date include/xen/interface/io/netif.h
> from the Xen Project brought in the necessary definitions to support the
> new control shared ring and protocol. This patch series updates xen-netback
> to support the new ring.

I lost my copy of your V3 cover letter, so I'm replying to this one, but
be sure I tested V3 :-)

This doesn't build, please fix:

ERROR: "init_rcu_head" [drivers/net/xen-netback/xen-netback.ko] undefined!
ERROR: "destroy_rcu_head" [drivers/net/xen-netback/xen-netback.ko] undefined!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next 2/4] xen-netback: add control protocol implementation

[David Miller]

From: Paul Durrant 
Date: Thu, 5 May 2016 12:19:28 +0100

> +struct xenvif_hash_cache {
> + rwlock_t lock;

You really don't want to lock on every SKB hash computation like
this, turn this into a spin lock for locking the write side and
use RCU locking for lookup and usage.

THanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next 0/3] xen-netback: fix multiple extra info handling

[David Miller]

From: Paul Durrant 
Date: Thu, 10 Mar 2016 12:30:25 +

> If a frontend passes multiple extra info fragments to netback on the guest
> transmit side, because xen-netback does not account for this properly, only
> a single ack response will be sent. This will eventually cause processing
> of the shared ring to wedge.
> 
> This series re-imports the canonical netif.h from Xen, where the ring
> protocol documentation has been updated, fixes this issue in xen-netback
> and also adds a patch to reduce log spam.

Series applied, thanks Paul.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] MAINTAINERS: Drop myself as xen netback maintainer

[David Miller]

From: Ian Campbell 
Date: Fri, 19 Feb 2016 11:44:51 +

> Wei has been picking this up for quite a while now.
> 
> Signed-off-by: Ian Campbell 

Applied, thanks Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON

[David Miller]

From: Gonglei 
Date: Sat, 20 Feb 2016 09:27:26 +0800

> It's possible for a race condition to exist between xennet_open() and
> talk_to_netback(). After invoking netfront_probe() then other
> threads or processes invoke xennet_open (such as NetworkManager)
> immediately may trigger BUG_ON(). Besides, we also should reset
> real_num_tx_queues in xennet_destroy_queues().

One should really never invoke register_netdev() until the device is
%100 fully initialized.

This means you cannot call register_netdev() until it is completely
legal to invoke your ->open() method.

And I think that is what the real problem is here.

If you follow the correct rules for ordering wrt. register_netdev()
there are no "races".  Because ->open() must be legally invokable
from the exact moment you call register_netdev().

I'm not applying this, as it really sounds like the fundamental issue
is the order in which the xen-netfront private data is initialized
or setup before being registered.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

[David Miller]

From: Paul Durrant 
Date: Fri, 12 Feb 2016 10:13:17 +

> This patch series adds support for frontend-configurable toeplitz hashing
> in xen-netback (on the guest receive side). This support has been testing
> against a Windows frontend and has proven to be sufficient to pass the
> Microsoft HCK NDIS RSS tests.

We want less Toeplitz users, not more of them.  It is a more unsuitable
hash than jhash2.

I'm not applying these patches, sorry.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

[David Miller]

From: Paul Durrant 
Date: Fri, 12 Feb 2016 11:07:50 +

> Windows *requires* use of Teoplitz so your position completely rules
> out being able to support receive side scaling in Windows PV
> frontends on Linux kernel backends, not only for Xen but for any
> other hypervisor, which I think is totally unreasonable.

We have strong reason to believe that Toeplitz has properties that
make it very weak if not exploitable, therefore doing software RSS
with Jenkins is superior.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v3] xen-netback: implement dynamic multicast control

[David Miller]

From: Paul Durrant 
Date: Tue, 2 Feb 2016 11:55:05 +

> My recent patch to the Xen Project documents a protocol for 'dynamic
> multicast control' in netif.h. This extends the previous multicast control
> protocol to not require a shared ring reconnection to turn the feature off.
> Instead the backend watches the "request-multicast-control" key in xenstore
> and turns the feature off if the key value is written to zero.
> 
> This patch adds support for dynamic multicast control in xen-netback.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Wei Liu 

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv2 net] xen-netfront: request Tx response events more often

[David Miller]

From: David Vrabel 
Date: Tue, 26 Jan 2016 17:12:44 +

> From: Malcolm Crossley 
> 
> Trying to batch Tx response events results in poor performance because
> this delays freeing the transmitted skbs.
> 
> Instead use the standard RING_FINAL_CHECK_FOR_RESPONSES() macro to be
> notified once the next Tx response is placed on the ring.
> 
> Signed-off-by: Malcolm Crossley 
> Signed-off-by: David Vrabel 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] stable backport of 3 xen multiqueue network dev fixes

[David Miller]

From: Ian Campbell 
Date: Thu, 21 Jan 2016 11:58:10 +

> Please could you queue these three:
> 
> 32a8440 xen-netfront: respect user provided max_queues
> 4c82ac3 xen-netback: respect user provided max_queues
> ca88ea1 xen-netfront: update num_queues to real created
> 
> for stable backports to at least 4.1. Multiqueue was added in v3.16 so I
> think they could all go to LTS that far back.

Done.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen-netback: fix license ident used in MODULE_LICENSE

[David Miller]

From: One Thousand Gnomes 
Date: Fri, 22 Jan 2016 20:25:21 +

>> The fact what include/linux/license.h:license_is_gpl_compatible includes
>> "Dual MIT/GPL" as an option seems to suggest that it is enough of a thing
>> to be validly used as the contents of a MODULE_LICENSE() thing.
> 
> Yes. The MIT licence most definitely exists, and people know what it
> means.
> 
> Also nobody should be changing the licence on anything unless they have
> the written permission of all rights holders on record, so it's best to
> leave it be 8)

+1

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 net] xen-netback: use skb to determine number of required guest Rx requests

[David Miller]

From: David Vrabel <david.vra...@citrix.com>
Date: Fri, 15 Jan 2016 10:31:57 +

> On 14/01/16 21:54, David Miller wrote:
>> From: David Vrabel <david.vra...@citrix.com>
>> Date: Thu, 14 Jan 2016 15:18:30 +
>> 
>>> -   needed = xenvif_rx_ring_slots_needed(queue->vif);
>>> +   skb = skb_peek(>rx_queue);
>>> +   if (!skb)
>>> +   return false;
>>> +
>>> +   needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
>>> +   if (skb_is_gso(skb))
>>> +   needed++;
>> 
>> If I am not mistaken, we moved away from this kind of test exactly because
>> it is inaccurate and may under-estimate the needs.
>> 
>> It is possible for an N byte SKB to require N segments.  Therefore, the:
>> 
>>  DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
>> 
>> calculation doesn't cut it.
> 
> After 1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b (xen-netback: always
> fully coalesce guest Rx packets) we always fully pack a packet into its
> guest Rx slots.  Each slot has space for XEN_PAGE_SIZE bytes so this
> calculation for the number of slots is correct.
> 
> Shall I resend with a more description changelog?

Yeah that would help a lot.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 net] xen-netfront: request Tx response events more often

[David Miller]

From: David Vrabel 
Date: Fri, 15 Jan 2016 11:56:42 +

> @@ -364,6 +364,7 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue)
>   RING_IDX cons, prod;
>   unsigned short id;
>   struct sk_buff *skb;
> + int more_to_do;

I hate to be difficult, but could you please use 'bool' for this variable?

Thanks!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv2 0/3 net] xen-netback: use skb to determine number of required (etc.)

[David Miller]

From: David Vrabel 
Date: Fri, 15 Jan 2016 14:55:33 +

> "xen-netback: use skb to determine number of required" plus two other
> minor fixes I found down the back of the sofa.

Series applied, thanks David.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 net] xen-netback: use skb to determine number of required guest Rx requests

[David Miller]

From: David Vrabel 
Date: Thu, 14 Jan 2016 15:18:30 +

> - needed = xenvif_rx_ring_slots_needed(queue->vif);
> + skb = skb_peek(>rx_queue);
> + if (!skb)
> + return false;
> +
> + needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
> + if (skb_is_gso(skb))
> + needed++;

If I am not mistaken, we moved away from this kind of test exactly because
it is inaccurate and may under-estimate the needs.

It is possible for an N byte SKB to require N segments.  Therefore, the:

DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);

calculation doesn't cut it.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 07/32] sparc: reuse asm-generic/barrier.h

[David Miller]

From: "Michael S. Tsirkin" 
Date: Thu, 31 Dec 2015 21:06:38 +0200

> On sparc 64 bit dma_rmb, dma_wmb, smp_store_mb, smp_mb, smp_rmb,
> smp_wmb, read_barrier_depends and smp_read_barrier_depends match the
> asm-generic variants exactly. Drop the local definitions and pull in
> asm-generic/barrier.h instead.
> 
> nop uses __asm__ __volatile but is otherwise identical to
> the generic version, drop that as well.
> 
> This is in preparation to refactoring this code area.
> 
> Note: nop() was in processor.h and not in barrier.h as on other
> architectures. Nothing seems to depend on it being there though.
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 

Acked-by: David S. Miller 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 24/32] sparc: define __smp_xxx

[David Miller]

From: "Michael S. Tsirkin" 
Date: Thu, 31 Dec 2015 21:08:53 +0200

> This defines __smp_xxx barriers for sparc,
> for use by virtualization.
> 
> smp_xxx barriers are removed as they are
> defined correctly by asm-generic/barriers.h
> 
> Signed-off-by: Michael S. Tsirkin 
> Acked-by: Arnd Bergmann 

Acked-by: David S. Miller 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next 0/8] xen-netback/core: packet hashing

[David Miller]

From: David Vrabel <david.vra...@citrix.com>
Date: Mon, 26 Oct 2015 10:38:50 +

> On 24/10/15 12:55, David Miller wrote:
>> From: Paul Durrant <paul.durr...@citrix.com>
>> Date: Wed, 21 Oct 2015 11:36:17 +0100
>> 
>>> This series adds xen-netback support for hash negotiation with a frontend
>>> driver, and an implementation of toeplitz hashing as the initial negotiable
>>> algorithm.
>> 
>> Ping, I want to see some review from some other xen networking folks.
> 
> There's been some review of the front/back protocol (on a different
> thread) and some significant changes have been suggested.

Ok, I'll mark this series as "changes requested" then, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next 0/8] xen-netback/core: packet hashing

[David Miller]

From: Paul Durrant 
Date: Wed, 21 Oct 2015 11:36:17 +0100

> This series adds xen-netback support for hash negotiation with a frontend
> driver, and an implementation of toeplitz hashing as the initial negotiable
> algorithm.

Ping, I want to see some review from some other xen networking folks.

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next 0/8] xen-netback/core: packet hashing

[David Miller]

From: Paul Durrant 
Date: Wed, 21 Oct 2015 11:36:17 +0100

> This series adds xen-netback support for hash negotiation with a frontend
> driver, and an implementation of toeplitz hashing as the initial negotiable
> algorithm.

I'd definitely like to see some XEN networking experts review this
before I apply it.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/1] xen-netfront: update num_queues to real created

[David Miller]

From: Joe Jin 
Date: Mon, 19 Oct 2015 13:37:17 +0800

> Sometimes xennet_create_queues() may failed to created all requested
> queues, we need to update num_queues to real created to avoid NULL
> pointer dereference.
> 
> Signed-off-by: Joe Jin 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netback: correctly check failed allocation

[David Miller]

From: Insu Yun 
Date: Thu, 15 Oct 2015 18:02:28 +

> Since vzalloc can be failed in memory pressure,
> writes -ENOMEM to xenstore to indicate error.
> 
> Signed-off-by: Insu Yun 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net-next v2] xen-netfront: always set num queues if possible

[David Miller]

From: "Charles (Chas) Williams" <3ch...@gmail.com>
Date: Wed, 16 Sep 2015 16:28:25 -0400

> If netfront connects with two (or more) queues and then reconnects with
> only one queue it fails to delete or rewrite the multi-queue-num-queues
> key and netback will try to use the wrong number of queues.
> 
> Always write the num-queues field if the backend has multi-queue support.
> 
> Signed-off-by: Chas Williams <3ch...@gmail.com>

Applied, thanks Chas.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 net] xen-netback: require fewer guest Rx slots when not using GSO

[David Miller]

From: David Vrabel 
Date: Tue, 15 Sep 2015 11:30:17 +0100

> This is causing regressions with certain frontend drivers.  Can you
> drop it, please?

All patches applied to my tree are part of the permanent record, and
this one even made it's way to Linus already I think.

So what you need to do is send me a revert.

Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net v3 0/2] xen-net{front, back}: respect user provided max_queues

[David Miller]

From: Wei Liu 
Date: Thu, 10 Sep 2015 11:18:56 +0100

> Wei Liu (2):
>   xen-netback: respect user provided max_queues
>   xen-netfront: respect user provided max_queues

This looks better, series applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net v2 0/2] xen-net{front, back}: respect user provided max_queues

[David Miller]

From: Wei Liu 
Date: Wed, 9 Sep 2015 11:23:04 +0100

> Wei Liu (2):
>   xen-netback: respect user provided max_queues
>   xen-netfront: respect user provided max_queues

Both applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net v2 0/2] xen-net{front, back}: respect user provided max_queues

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Wed, 09 Sep 2015 21:53:22 -0700 (PDT)

> From: Wei Liu <wei.l...@citrix.com>
> Date: Wed, 9 Sep 2015 11:23:04 +0100
> 
>> Wei Liu (2):
>>   xen-netback: respect user provided max_queues
>>   xen-netfront: respect user provided max_queues
> 
> Both applied, thanks.

Yo, this doesn't even compile!

drivers/net/xen-netfront.c: In function ‘netif_init’:
drivers/net/xen-netfront.c:2138:6: error: ‘xenvif_max_queues’ undeclared (first 
use in this function)
  if (xenvif_max_queues == 0)
  ^
drivers/net/xen-netfront.c:2138:6: note: each undeclared identifier is reported 
only once for each function it appears in

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 net] xen-netback: require fewer guest Rx slots when not using GSO

[David Miller]

From: David Vrabel 
Date: Tue, 8 Sep 2015 14:25:14 +0100

> Commit f48da8b14d04ca87ffcffe68829afd45f926ec6a (xen-netback: fix
> unlimited guest Rx internal queue and carrier flapping) introduced a
> regression.
> 
> The PV frontend in IPXE only places 4 requests on the guest Rx ring.
> Since netback required at least (MAX_SKB_FRAGS + 1) slots, IPXE could
> not receive any packets.
> 
> a) If GSO is not enabled on the VIF, fewer guest Rx slots are required
>for the largest possible packet.  Calculate the required slots
>based on the maximum GSO size or the MTU.
> 
>This calculation of the number of required slots relies on
>1650d5455bd2 (xen-netback: always fully coalesce guest Rx packets)
>which present in 4.0-rc1 and later.
> 
> b) Reduce the Rx stall detection to checking for at least one
>available Rx request.  This is fine since we're predominately
>concerned with detecting interfaces which are down and thus have
>zero available Rx requests.
> 
> Signed-off-by: David Vrabel 

Applied, thanks David.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for multicast control

[David Miller]

From: Paul Durrant 
Date: Wed, 2 Sep 2015 17:58:36 +0100

> Xen's PV network protocol includes messages to add/remove ethernet
> multicast addresses to/from a filter list in the backend. This allows
> the frontend to request the backend only forward multicast packets
> which are of interest thus preventing unnecessary noise on the shared
> ring.
> 
> The canonical netif header in git://xenbits.xen.org/xen.git specifies
> the message format (two more XEN_NETIF_EXTRA_TYPEs) so the minimal
> necessary changes have been pulled into include/xen/interface/io/netif.h.
> 
> To prevent the frontend from extending the multicast filter list
> arbitrarily a limit (XEN_NETBK_MCAST_MAX) has been set to 64 entries.
> This limit is not specified by the protocol and so may change in future.
> If the limit is reached then the next XEN_NETIF_EXTRA_TYPE_MCAST_ADD
> sent by the frontend will be failed with NETIF_RSP_ERROR.
> 
> Signed-off-by: Paul Durrant 

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netback: Allocate fraglist early to avoid complex rollback

[David Miller]

From: Ross Lagerwall ross.lagerw...@citrix.com
Date: Mon, 3 Aug 2015 15:38:03 +0100

 Determine if a fraglist is needed in the tx path, and allocate it if
 necessary before setting up the copy and map operations.
 Otherwise, undoing the copy and map operations is tricky.
 
 This fixes a use-after-free: if allocating the fraglist failed, the copy
 and map operations that had been set up were still executed, writing
 over the data area of a freed skb.
 
 Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [patch] net/xen-netback: off by one in BUG_ON() condition

[David Miller]

From: Dan Carpenter dan.carpen...@oracle.com
Date: Sun, 12 Jul 2015 01:20:55 +0300

 The  should be =.  I also added spaces around the '-' operations so
 the code is a little more consistent and matches the condition better.
 
 Fixes: f53c3fe8dad7 ('xen-netback: Introduce TX grant mapping')
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

Applied and queued up for -stable, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RESEND] xen-netback: remove duplicated function definition

[David Miller]

From: Liang Li liang.z...@intel.com
Date: Mon,  6 Jul 2015 08:42:56 +0800

 There are two duplicated xenvif_zerocopy_callback() definitions.
 Remove one of them.
 
 Signed-off-by: Liang Li liang.z...@intel.com

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netback: remove duplicated function definition

[David Miller]

From: Liang Li liang.z...@intel.com
Date: Sat,  4 Jul 2015 03:33:00 +0800

 There are two duplicated xenvif_zerocopy_callback() definitions.
 Remove one of them.
 
 Signed-off-by: Liang Li liang.z...@intel.com

You really need to fix the date on your computer.

If your date is in the future, as your's is, then your patch appears
out-of-order in the patchwork patch queue since it is ordered by the
Date: field in the email.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netfront: Remove the meaningless code

[David Miller]

From: David Vrabel david.vra...@citrix.com
Date: Fri, 26 Jun 2015 16:15:18 +0100

 On 27/06/15 00:17, Liang Li wrote:
 The function netif_set_real_num_tx_queues() will return -EINVAL if
 the second parameter  1, so call this function with the second
 parameter set to 0 is meaningless.
 
 Reviewed-by: David Vrabel david.vra...@citrix.com

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/3] net/xen-netback: Remove unused code in xenvif_rx_action

[David Miller]

From: Julien Grall julien.gr...@citrix.com
Date: Tue, 16 Jun 2015 20:10:47 +0100

 The variables old_req_cons and ring_slots_used are assigned but never
 used since commit 1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b xen-netback:
 always fully coalesce guest Rx packets.
 
 Signed-off-by: Julien Grall julien.gr...@citrix.com
 Acked-by: Wei Liu wei.l...@citrix.com

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 1/3] net/xen-netfront: Correct printf format in xennet_get_responses

[David Miller]

From: Julien Grall julien.gr...@citrix.com
Date: Tue, 16 Jun 2015 20:10:46 +0100

 rx-status is an int16_t, print it using %d rather than %u in order to
 have a meaningful value when the field is negative.
 
 Also use %u rather than %x for rx-offset.
 
 Signed-off-by: Julien Grall julien.gr...@citrix.com
 Reviewed-by: David Vrabel david.vra...@citrix.com

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 1/2] net/xen-netfront: Correct printf format in xennet_get_responses

[David Miller]

From: Julien Grall julien.gr...@citrix.com
Date: Thu, 4 Jun 2015 16:35:13 +0100

 rx-status is an int16_t, print it using %d rather than %u in order to
 have a meaningful value when the field is negative.
 
 Also use %d rather than %x for rx-offset.
 
 Signed-off-by: Julien Grall julien.gr...@citrix.com
 Reviewed-by: David Vrabel david.vra...@citrix.com
 Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 Cc: Boris Ostrovsky boris.ostrov...@oracle.com
 Cc: net...@vger.kernel.org
 
 ---
 Changes in v3:
 - Use %d for the rx-offset too.

This change in v3 is wrong, 'rx-offset' is unsigned therefore %u is
the correct format string to use.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 net] xen: netback: read hotplug script once at start of day.

[David Miller]

From: Ian Campbell ian.campb...@citrix.com
Date: Mon, 1 Jun 2015 11:30:24 +0100

 When we come to tear things down in netback_remove() and generate the
 uevent it is possible that the xenstore directory has already been
 removed (details below).
 
 In such cases netback_uevent() won't be able to read the hotplug
 script and will write a xenstore error node.
 
 A recent change to the hypervisor exposed this race such that we now
 sometimes lose it (where apparently we didn't ever before).
 
 Instead read the hotplug script configuration during setup and use it
 for the lifetime of the backend device.
 
 The apparently more obvious fix of moving the transition to
 state=Closed in netback_remove() to after the uevent does not work
 because it is possible that we are already in state=Closed (in
 reaction to the guest having disconnected as it shutdown). Being
 already in Closed means the toolstack is at liberty to start tearing
 down the xenstore directories. In principal it might be possible to
 arrange to unregister the device sooner (e.g on transition to Closing)
 such that xenstore would still be there but this state machine is
 fragile and prone to anger...
 
 A modern Xen system only relies on the hotplug uevent for driver
 domains, when the backend is in the same domain as the toolstack it
 will run the necessary setup/teardown directly in the correct sequence
 wrt xenstore changes.
 
 Signed-off-by: Ian Campbell ian.campb...@citrix.com

Applied and queued up for -stable, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen: netback: fix printf format string warning

[David Miller]

From: Ian Campbell ian.campb...@citrix.com
Date: Mon, 1 Jun 2015 11:30:04 +0100

 drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
 drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects 
 argument of type ‘long unsigned int’, but argument 5 has type ‘int’ 
 [-Wformat=]
 (txreq.offset~PAGE_MASK) + txreq.size);
 ^
 
 PAGE_MASK's type can vary by arch, so a cast is needed.
 
 Signed-off-by: Ian Campbell ian.campb...@citrix.com
 
 v2: Cast to unsigned long, since PAGE_MASK can vary by arch.

Applied.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC][PATCH] x86: remove vmalloc.h from asm/io.h

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Fri, 29 May 2015 19:18:47 +1000

 Nothing in asm/io.h uses anything from vmalloc.h, so remove the include
 and fix up the build problems in an allmodconfig (64 bit and 32 bit)
 build.
 
 This may be the place where x86 builds get vmalloc.h implicitly included
 and that tends to hide places where vmalloc() et al are added to files
 but the include of vmalloc.h is forgotten.
 
 ...
 Suggested-by: David Miller da...@davemloft.net
 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au

With the follow-on allnoconfig fixes:

Acked-by: David S. Miller da...@davemloft.net

Thanks a lot for doing this!

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-netfront: Use setup_timer

[David Miller]

From: Vaishali Thakkar vthakkar1...@gmail.com
Date: Mon, 1 Jun 2015 10:28:37 +0530

 Use the timer API function setup_timer instead of structure field
 assignments to initialize a timer.
 
 A simplified version of the Coccinelle semantic patch that performs
 this transformation is as follows:
 
 @change@
 expression e, func, da;
 @@
 
 -init_timer (e);
 +setup_timer (e, func, da);
 -e.data = da;
 -e.function = func;
 
 Signed-off-by: Vaishali Thakkar vthakkar1...@gmail.com

Applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: netback: fix error printf format string.

[David Miller]

From: Ian Campbell ian.campb...@citrix.com
Date: Fri, 29 May 2015 17:22:04 +0100

 drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
 drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects 
 argument of type ‘long unsigned int’, but argument 5 has type ‘int’ 
 [-Wformat=]
 (txreq.offset~PAGE_MASK) + txreq.size);
 ^
 
 txreq.offset and .size are uint16_t fields.
 
 Signed-off-by: Ian Campbell ian.campb...@citrix.com

This may get rid of the compiler warning on your machine, but it creates
one on mine:

drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%u’ expects argument 
of type ‘unsigned int’, but argument 5 has type ‘long unsigned int’ [-Wformat=]
(txreq.offset~PAGE_MASK) + txreq.size);
^

There is a type involved in this calculation which is arch
dependent, so you'll need to add a cast or something to
make this warning go away in all cases.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1] xen-netfront: properly destroy queues when removing device

[David Miller]

From: David Vrabel david.vra...@citrix.com
Date: Wed, 27 May 2015 15:46:10 +0100

 xennet_remove() freed the queues before freeing the netdevice which
 results in a use-after-free when free_netdev() tries to delete the
 napi instances that have already been freed.
 
 Fix this by fully destroy the queues (which includes deleting the napi
 instances) before freeing the netdevice.
 
 Signed-off-by: David Vrabel david.vra...@citrix.com

Applied, thanks David.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net v2] xen/netback: Properly initialize credit_bytes

[David Miller]

From: Ross Lagerwall ross.lagerw...@citrix.com
Date: Wed, 27 May 2015 11:44:32 +0100

 Commit e9ce7cb6b107 (xen-netback: Factor queue-specific data into queue
 struct) introduced a regression when moving queue-specific data into
 the queue struct by failing to set the credit_bytes field. This
 prevented bandwidth limiting from working. Initialize the field as it
 was done before multiqueue support was added.
 
 Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com

Applied, thanks Ross.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] net:xen-netback - Change 1 to true for bool type variable.

[David Miller]

From: Shailendra Verma shailendra.capric...@gmail.com
Date: Mon, 25 May 2015 23:19:31 +0530

 The variable separate_tx_rx_irq is bool type so assigning true
 instead of 1.
 
 Signed-off-by: Shailendra Verma shailendra.capric...@gmail.com

Applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

[David Miller]

From: Ian Jackson ian.jack...@eu.citrix.com
Date: Fri, 17 Apr 2015 17:29:28 +0100

 Prashant Sreedharan writes (Re: tg3 NIC driver bug in 3.14.x under Xen [and 
 3 more messages]):
 Ok this is what is causing the problem, the driver uses
 DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma
 mapping and dma_unmap_addr() to get the mapping value. On most of
 the platforms this is a no-op, but it appears with iommu=soft and
 swiotlb=force this house keeping is required, when I pass the correct
 dma_addr instead of 0 while calling pci_unmap_/pci_dma_sync_ I don't see
 the corruption. ie If you set CONFIG_NEED_DMA_MAP_STATE=y in your kernel
 config you should not see the problem. Can you confirm ? Thanks
 
 That kernel config option is an automatically computed one:
 
 config NEED_DMA_MAP_STATE
 def_bool y
 depends on X86_64 || INTEL_IOMMU || DMA_API_DEBUG
 
 and grepping my .config shows:
 
 # CONFIG_INTEL_IOMMU is not set
 # CONFIG_DMA_API_DEBUG is not set
 
 It's a 32-bit kernel so it hasn't got X86_64 enabled either.
 
 Arguably at least some of osstest's kernels should have INTEL_IOMMU
 enabled to detect conflicts between Xen's use of the iommu and
 possible attempts bo Linux to do the same thing, but not having it
 enabled should not cause a driver bug.

So the gist of the situation is, that NEED_DMA_MAP_STATE can be 'n' in
situations where we might actually need it to be 'y' based upon kernel
comman line boot options given.

Right?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

[David Miller]

From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Fri, 17 Apr 2015 15:04:48 -0400

 From 9e417af099e3cee2b219ab28ffc1e96b0564b213 Mon Sep 17 00:00:00 2001
 From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 Date: Fri, 17 Apr 2015 14:55:47 -0400
 Subject: [PATCH] config: Enable NEED_DMA_MAP_STATE when SWIOTLB is selected
 
 A huge amount of NIC drivers use the DMA API, however if compiled
 under 32-bit an very important part of the DMA API can be ommitted leading
 to the drivers not working at all (especially if used with
 'swiotlb=force iommu=soft').
 
 As Prashant Sreedharan explains it: the driver [tg3] uses
 DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma
 mapping and dma_unmap_addr() to get the mapping value. On most of
 the platforms this is a no-op, but ... with iommu=soft and
 swiotlb=force this house keeping is required, ... otherwise
 we pass 0 while calling pci_unmap_/pci_dma_sync_ instead of the
 DMA address.
 
 As such enable this even when using 32-bit kernels.
 
 Reported-by: Ian Jackson ian.jack...@eu.citrix.com
 Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com

Acked-by: David S. Miller da...@davemloft.net

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

[David Miller]

From: Michael Chan mc...@broadcom.com
Date: Thu, 16 Apr 2015 09:39:13 -0700

 On Thu, 2015-04-16 at 09:24 -0300, casca...@linux.vnet.ibm.com wrote: 
 Yes, this looks like the driver is not syncing the DMA buffers. Unmap is
 supposed to synchronize as well.
 
 
 For small rx packets ( 256 bytes), we sync the DMA buffer before we
 copy the data to another SKB.  For larger packets, we unmap the DMA
 buffer.  Do we see the corruption in both cases?

I wonder about that prefetch which is done before the DMA sync.

Also we should think about whether that DMA sync applies to the proper
region.  The 'len' is relative to data+TG3_RX_OFFSET yet if I read
the code correctly we are effectively sync'ing from 'data' to
'data+len'.

There is some bug hiding in here I think...

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen-netback: making the bandwidth limiter runtime settable

[David Miller]

From: Imre Palik imrep@gmail.com
Date: Thu, 19 Mar 2015 11:05:42 +0100

 From: Palik, Imre im...@amazon.de
 
 With the current netback, the bandwidth limiter's parameters are only
 settable during vif setup time.  This patch register a watch on them, and
 thus makes them runtime changeable.
 
 When the watch fires, the timer is reset.  The timer's mutex is used for
 fencing the change.
 
 Cc: Anthony Liguori aligu...@amazon.com
 Signed-off-by: Imre Palik im...@amazon.de

Applied to net-next, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 net] xen-netback: notify immediately after pushing Tx response.

[David Miller]

From: David Vrabel david.vra...@citrix.com
Date: Wed, 11 Mar 2015 15:27:59 +

 This fixes a performance regression introduced by
 7fbb9d8415d4a51cf542e87cf3a717a9f7e6aedc (xen-netback: release pending
 index before pushing Tx responses)
 
 Moving the notify outside of the spin locks means it can be delayed a
 long time (if the dealloc thread is descheduled or there is an
 interrupt or softirq).
 
 Signed-off-by: David Vrabel david.vra...@citrix.com

Applied, thanks David.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv2 0/3 net] xen-netback: fix ethtool stats and memory leak

[David Miller]

From: David Vrabel david.vra...@citrix.com
Date: Wed, 4 Mar 2015 11:14:45 +

 A couple of bug fixes for netback:
 - make ethool stats to report the correct values.
 - don't leak 1 MiB every time a VIF is destroyed.
 
 Changes in v2:
 - Split 2nd patch into leak fix and refactor patches

Series applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 0/2 net] xen-netback: fix ethtool stats and memory

[David Miller]

From: David Vrabel david.vra...@citrix.com
Date: Tue, 3 Mar 2015 16:26:09 +

 A couple of bug fixes for netback:
 - make ethool stats to report the correct values.
 - don't leak 1 MiB every time a VIF is destroyed.

Please fix up the minor commit message issues in patch #2
and resubmit this series, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel