From patchwork Thu Mar 2 01:05:21 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 9599385 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9E0C3604A8 for ; Thu, 2 Mar 2017 01:07:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8278328552 for ; Thu, 2 Mar 2017 01:07:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 743A82857F; Thu, 2 Mar 2017 01:07:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id E6F342853B for ; Thu, 2 Mar 2017 01:07:58 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjFBR-0002Tn-5k; Thu, 02 Mar 2017 01:05:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjFBP-0002Tf-VJ for xen-devel@lists.xenproject.org; Thu, 02 Mar 2017 01:05:28 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id A4/42-01926-6DF67B85; Thu, 02 Mar 2017 01:05:26 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRWlGSWpSXmKPExsVybKJsh+61/O0 RBi8nclp83zKZyYHR4/CHKywBjFGsmXlJ+RUJrBlTO98yF3wWrGj5ItfA+Jm3i5GLQ0hgKqPE 7B+HGCGc2UwSZ/6+Yuti5ORgEdCSmNf4gRnEZhMwlPj7ZBNQnINDAshe8pkDJCwiICtxa8s0s HJmgVCJA1sesYPYwgJWEjd/HWMEsXkFvCWWfVwOFhcV0JU49O8PG0RcUOLkzCcsEL1aEsunbw OzJQQyJOb1zGGFsL0kFt24BGWrSVw9t4l5AiP/LCTts5C0L2BkWsWoXpxaVJZapGukl1SUmZ5 RkpuYmaNraGCql5taXJyYnpqTmFSsl5yfu4kRGGoMQLCD8fsfp0OMkhxMSqK899O2RwjxJeWn VGYkFmfEF5XmpBYfYpTh4FCS4J2TB5QTLEpNT61Iy8wBBj1MWoKDR0mEd1YuUJq3uCAxtzgzH SJ1ilGX41bDnjdMQix5+XmpUuK8gSAzBECKMkrz4EbAIvASo6yUMC8j0FFCPAWpRbmZJajyrx jFORiVhHnlQabwZOaVwG16BXQEE9ARL1S2ghxRkoiQkmpgFOPllaxM+LFhlfQvRd55hn2iYns OH70e87OLaytbUkTAcr5tsQfuCLYpZ4plMPyaGVE245D2L1Y90dhZHmyXcqLqD7+YvIhZs9n+ S5avH/vcBYdrw+KjGDI2MZR8spaf+t5zpzmLqtirnxxb1th+Uup21J1xrmjhjRvdgSUX0t78P ni4Yd5XJZbijERDLeai4kQAJRZ06LsCAAA= X-Env-Sender: sstabellini@kernel.org X-Msg-Ref: server-7.tower-206.messagelabs.com!1488416724!84531805!1 X-Originating-IP: [198.145.29.136] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17452 invoked from network); 2 Mar 2017 01:05:26 -0000 Received: from mail.kernel.org (HELO mail.kernel.org) (198.145.29.136) by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 2 Mar 2017 01:05:26 -0000 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2F4CC20544; Thu, 2 Mar 2017 01:05:23 +0000 (UTC) Received: from [10.1.10.56] (96-82-76-110-static.hfc.comcastbusiness.net [96.82.76.110]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 16D372053E; Thu, 2 Mar 2017 01:05:22 +0000 (UTC) Date: Wed, 1 Mar 2017 17:05:21 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-X260 To: edgar.iglesias@xilinx.com Message-ID: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV using ClamSMTP Cc: xen-devel@lists.xenproject.org, julien.grall@arm.com, sstabellini@kernel.org Subject: [Xen-devel] xen/arm and swiotlb-xen: possible data corruption X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Hi all, Edgar reported a data corruption on network packets in dom0 when the swiotlb-xen is in use. He also reported that the following patch "fixes" the problem for him: static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle, size_t size, enum dma_data_direction dir) { - dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP); + printk("%s: addr=%lx size=%zd\n", __func__, handle, size); + dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size + 64, dir, DMA_MAP); I am thinking that the problem has something to do with cacheline alignment on the Xen side (xen/common/grant_table.c:__gnttab_cache_flush). If op == GNTTAB_CACHE_INVAL, we call invalidate_dcache_va_range; if op == GNTTAB_CACHE_CLEAN, we call clean_dcache_va_range instead. The parameter, v, could be non-cacheline aligned. invalidate_dcache_va_range is capable of handling a not aligned address, while clean_dcache_va_range does not. Edgar, does the appended patch fix the problem for you? diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h index 86de0b6..9cdf2fb 100644 --- a/xen/include/asm-arm/page.h +++ b/xen/include/asm-arm/page.h @@ -322,10 +322,30 @@ static inline int invalidate_dcache_va_range(const void *p, unsigned long size) static inline int clean_dcache_va_range(const void *p, unsigned long size) { - const void *end; + size_t off; + const void *end = p + size; + dsb(sy); /* So the CPU issues all writes to the range */ - for ( end = p + size; p < end; p += cacheline_bytes ) + + off = (unsigned long)p % cacheline_bytes; + if ( off ) + { + p -= off; asm volatile (__clean_dcache_one(0) : : "r" (p)); + p += cacheline_bytes; + size -= cacheline_bytes - off; + } + off = (unsigned long)end % cacheline_bytes; + if ( off ) + { + end -= off; + size -= off; + asm volatile (__clean_dcache_one(0) : : "r" (end)); + } + + for ( ; p < end; p += cacheline_bytes ) + asm volatile (__clean_dcache_one(0) : : "r" (p)); + dsb(sy); /* So we know the flushes happen before continuing */ /* ARM callers assume that dcache_* functions cannot fail. */ return 0;