Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1236132 > unrolled thread

[PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux

Started byJulien Grall <julien.grall@citrix.com>
First post2015-09-30 12:50 +0200
Last post2015-10-01 17:20 +0200
Articles 6 on this page of 26 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux Julien Grall <julien.grall@citrix.com> - 2015-09-30 12:50 +0200
    [PATCH v5 02/22] arm/xen: Drop pte_mfn and mfn_pte Julien Grall <julien.grall@citrix.com> - 2015-09-30 12:50 +0200
    [PATCH v5 07/22] block/xen-blkfront: Store a page rather a pfn in the grant structure Julien Grall <julien.grall@citrix.com> - 2015-09-30 12:50 +0200
    [PATCH v5 09/22] xen/biomerge: Don't allow biovec's to be merged when Linux is not using 4KB pages Julien Grall <julien.grall@citrix.com> - 2015-09-30 12:50 +0200
    [PATCH v5 20/22] arm/xen: Add support for 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 10/22] xen/xenbus: Use Xen page definition Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 16/22] block/xen-blkback: Make it running on 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 11/22] tty/hvc: xen: Use xen page definition Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 22/22] xen/swiotlb: Add support for 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 19/22] xen/privcmd: Add support for Linux 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 17/22] net/xen-netfront: Make it running on 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 14/22] xen/grant-table: Make it running on 64KB granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity is the same for Xen and Linux Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
      Re: [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity  is the same for Xen and Linux David Vrabel <david.vrabel@citrix.com> - 2015-10-02 16:10 +0200
        Re: [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity  is the same for Xen and Linux Julien Grall <julien.grall@citrix.com> - 2015-10-02 16:40 +0200
          Re: [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity  is the same for Xen and Linux Julien Grall <julien.grall@citrix.com> - 2015-10-02 17:00 +0200
            Re: [PATCH v5 12/22] xen/balloon: Don't rely on the page granularity  is the same for Xen and Linux Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2015-10-02 17:20 +0200
            Re: [Xen-devel] [PATCH v5 12/22] xen/balloon: Don't rely on the page  granularity is the same for Xen and Linux David Vrabel <david.vrabel@citrix.com> - 2015-10-02 17:20 +0200
    [PATCH v5 15/22] block/xen-blkfront: Make it running on 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 13/22] xen/events: fifo: Make it running on 64KB granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 21/22] xen/swiotlb: Pass addresses rather than frame numbers to xen_arch_need_swiotlb Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    [PATCH v5 18/22] net/xen-netback: Make it running on 64KB page granularity Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:00 +0200
    Re: [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux Mark Rutland <mark.rutland@arm.com> - 2015-09-30 13:40 +0200
      Re: [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux Julien Grall <julien.grall@citrix.com> - 2015-09-30 13:50 +0200
        Re: [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux Mark Rutland <mark.rutland@arm.com> - 2015-09-30 15:10 +0200
    Re: [Xen-devel] [PATCH v5 00/22] xen/arm64: Add support for 64KB  page in Linux David Vrabel <david.vrabel@citrix.com> - 2015-10-01 17:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1236156 — [PATCH v5 21/22] xen/swiotlb: Pass addresses rather than frame numbers to xen_arch_need_swiotlb

FromJulien Grall <julien.grall@citrix.com>
Date2015-09-30 13:00 +0200
Subject[PATCH v5 21/22] xen/swiotlb: Pass addresses rather than frame numbers to xen_arch_need_swiotlb
Message-ID<qenh9-2Ko-41@gated-at.bofh.it>
In reply to#1236132
With 64KB page granularity support, the frame number will be different.

It will be easier to modify the behavior in a single place rather than
in each caller.

Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org

    Changes in v5:
        - Patch was previously sent separately
        - Fix compilation on x86 (spurious ; at the end of the
        declaration)
        - Add Stefano's reviewed-by
---
 arch/arm/include/asm/xen/page.h | 4 ++--
 arch/arm/xen/mm.c               | 7 +++++--
 arch/x86/include/asm/xen/page.h | 4 ++--
 drivers/xen/swiotlb-xen.c       | 4 ++--
 4 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index e3d94cf..415dbc6 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -115,8 +115,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 #define xen_unmap(cookie) iounmap((cookie))
 
 bool xen_arch_need_swiotlb(struct device *dev,
-			   unsigned long pfn,
-			   unsigned long bfn);
+			   phys_addr_t phys,
+			   dma_addr_t dev_addr);
 unsigned long xen_get_swiotlb_free_pages(unsigned int order);
 
 #endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 6dd911d..7b517e91 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -138,9 +138,12 @@ void __xen_dma_sync_single_for_device(struct device *hwdev,
 }
 
 bool xen_arch_need_swiotlb(struct device *dev,
-			   unsigned long pfn,
-			   unsigned long bfn)
+			   phys_addr_t phys,
+			   dma_addr_t dev_addr)
 {
+	unsigned long pfn = PFN_DOWN(phys);
+	unsigned long bfn = PFN_DOWN(dev_addr);
+
 	return (!hypercall_cflush && (pfn != bfn) && !is_device_dma_coherent(dev));
 }
 
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index fe58e3a..f5fb840 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -298,8 +298,8 @@ void make_lowmem_page_readwrite(void *vaddr);
 #define xen_unmap(cookie) iounmap((cookie))
 
 static inline bool xen_arch_need_swiotlb(struct device *dev,
-					 unsigned long pfn,
-					 unsigned long bfn)
+					 phys_addr_t phys,
+					 dma_addr_t dev_addr)
 {
 	return false;
 }
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 79bc493..0a5a0e9 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -392,7 +392,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 	 */
 	if (dma_capable(dev, dev_addr, size) &&
 	    !range_straddles_page_boundary(phys, size) &&
-		!xen_arch_need_swiotlb(dev, PFN_DOWN(phys), PFN_DOWN(dev_addr)) &&
+		!xen_arch_need_swiotlb(dev, phys, dev_addr) &&
 		!swiotlb_force) {
 		/* we are not interested in the dma_addr returned by
 		 * xen_dma_map_page, only in the potential cache flushes executed
@@ -551,7 +551,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 		dma_addr_t dev_addr = xen_phys_to_bus(paddr);
 
 		if (swiotlb_force ||
-		    xen_arch_need_swiotlb(hwdev, PFN_DOWN(paddr), PFN_DOWN(dev_addr)) ||
+		    xen_arch_need_swiotlb(hwdev, paddr, dev_addr) ||
 		    !dma_capable(hwdev, dev_addr, sg->length) ||
 		    range_straddles_page_boundary(paddr, sg->length)) {
 			phys_addr_t map = swiotlb_tbl_map_single(hwdev,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236157 — [PATCH v5 18/22] net/xen-netback: Make it running on 64KB page granularity

FromJulien Grall <julien.grall@citrix.com>
Date2015-09-30 13:00 +0200
Subject[PATCH v5 18/22] net/xen-netback: Make it running on 64KB page granularity
Message-ID<qenh9-2Ko-33@gated-at.bofh.it>
In reply to#1236132
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.

It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the grant table code.

Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>

---
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: netdev@vger.kernel.org

Improvement such as support of 64KB grant is not taken into
consideration in this patch because we have the requirement to run a
Linux using 64KB pages on a non-modified Xen.

Note that I haven't add a comment why the offset is 0 after the first
iteration. See [1] for more details.

[1] https://lkml.org/lkml/2015/8/10/456

    Wei, I have kept your reviewed-by because the conflict during rebase
    with with 1d5d48523900a4b0f25d6b52f1a93c84bd671186
    "xen-netback: require fewer guest Rx slots when not using GSO" was
    trivial to resolve. It's basically drop XEN_NETBK_RX_SLOTS_MAX and
    replace the new PAGE_SIZE by XEN_PAGE_SIZE. Let me know if it's not
    okay.

    Changes in v5:
        - Add Wei's reviewed-by
        - Fix conflict with 1d5d48523900a4b0f25d6b52f1a93c84bd671186

    Changes in v4:
        - Add a comment to explain how we compute MAX_XEN_SKB_FRAGS

    Changes in v3:
        - Fix errors reported by checkpatch.pl
        - s/mfn/gfn/ based on the new naming
        - gnttab_foreach_grant has been renamed to gnttab_forach_grant_in_range
        - The grant callback doesn't allow anymore to use less data. An
        helpers has been added in netback to handle this.

    Changes in v2:
        - Correctly set MAX_GRANT_COPY_OPS and XEN_NETBK_RX_SLOTS_MAX
        - Don't use XEN_PAGE_SIZE in handle_frag_list as we coalesce
        fragment into a new skb
        - Use gnntab_foreach_grant to split a Linux page into grant
---
 drivers/net/xen-netback/common.h  |  16 ++--
 drivers/net/xen-netback/netback.c | 157 ++++++++++++++++++++++++--------------
 2 files changed, 111 insertions(+), 62 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index a7bf747..0333ab0 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -44,6 +44,7 @@
 #include <xen/interface/grant_table.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
+#include <xen/page.h>
 #include <linux/debugfs.h>
 
 typedef unsigned int pending_ring_idx_t;
@@ -64,8 +65,8 @@ struct pending_tx_info {
 	struct ubuf_info callback_struct;
 };
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, XEN_PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, XEN_PAGE_SIZE)
 
 struct xenvif_rx_meta {
 	int id;
@@ -80,16 +81,21 @@ struct xenvif_rx_meta {
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
 
-#define MAX_BUFFER_OFFSET PAGE_SIZE
+#define MAX_BUFFER_OFFSET XEN_PAGE_SIZE
 
 #define MAX_PENDING_REQS XEN_NETIF_TX_RING_SIZE
 
+/* The maximum number of frags is derived from the size of a grant (same
+ * as a Xen page size for now).
+ */
+#define MAX_XEN_SKB_FRAGS (65536 / XEN_PAGE_SIZE + 1)
+
 /* It's possible for an skb to have a maximal number of frags
  * but still be less than MAX_BUFFER_OFFSET in size. Thus the
- * worst-case number of copy operations is MAX_SKB_FRAGS per
+ * worst-case number of copy operations is MAX_XEN_SKB_FRAGS per
  * ring slot.
  */
-#define MAX_GRANT_COPY_OPS (MAX_SKB_FRAGS * XEN_NETIF_RX_RING_SIZE)
+#define MAX_GRANT_COPY_OPS (MAX_XEN_SKB_FRAGS * XEN_NETIF_RX_RING_SIZE)
 
 #define NETBACK_INVALID_HANDLE -1
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index c4e6c02..e481f37 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -152,9 +152,9 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 static int xenvif_rx_ring_slots_needed(struct xenvif *vif)
 {
 	if (vif->gso_mask)
-		return DIV_ROUND_UP(vif->dev->gso_max_size, PAGE_SIZE) + 1;
+		return DIV_ROUND_UP(vif->dev->gso_max_size, XEN_PAGE_SIZE) + 1;
 	else
-		return DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
+		return DIV_ROUND_UP(vif->dev->mtu, XEN_PAGE_SIZE);
 }
 
 static bool xenvif_rx_ring_slots_available(struct xenvif_queue *queue)
@@ -274,6 +274,80 @@ static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif_queue *queue,
 	return meta;
 }
 
+struct gop_frag_copy {
+	struct xenvif_queue *queue;
+	struct netrx_pending_operations *npo;
+	struct xenvif_rx_meta *meta;
+	int head;
+	int gso_type;
+
+	struct page *page;
+};
+
+static void xenvif_setup_copy_gop(unsigned long gfn,
+				  unsigned int offset,
+				  unsigned int *len,
+				  struct gop_frag_copy *info)
+{
+	struct gnttab_copy *copy_gop;
+	struct xen_page_foreign *foreign;
+	/* Convenient aliases */
+	struct xenvif_queue *queue = info->queue;
+	struct netrx_pending_operations *npo = info->npo;
+	struct page *page = info->page;
+
+	BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
+
+	if (npo->copy_off == MAX_BUFFER_OFFSET)
+		info->meta = get_next_rx_buffer(queue, npo);
+
+	if (npo->copy_off + *len > MAX_BUFFER_OFFSET)
+		*len = MAX_BUFFER_OFFSET - npo->copy_off;
+
+	copy_gop = npo->copy + npo->copy_prod++;
+	copy_gop->flags = GNTCOPY_dest_gref;
+	copy_gop->len = *len;
+
+	foreign = xen_page_foreign(page);
+	if (foreign) {
+		copy_gop->source.domid = foreign->domid;
+		copy_gop->source.u.ref = foreign->gref;
+		copy_gop->flags |= GNTCOPY_source_gref;
+	} else {
+		copy_gop->source.domid = DOMID_SELF;
+		copy_gop->source.u.gmfn = gfn;
+	}
+	copy_gop->source.offset = offset;
+
+	copy_gop->dest.domid = queue->vif->domid;
+	copy_gop->dest.offset = npo->copy_off;
+	copy_gop->dest.u.ref = npo->copy_gref;
+
+	npo->copy_off += *len;
+	info->meta->size += *len;
+
+	/* Leave a gap for the GSO descriptor. */
+	if (info->head && ((1 << info->gso_type) & queue->vif->gso_mask))
+		queue->rx.req_cons++;
+
+	info->head = 0; /* There must be something in this buffer now */
+}
+
+static void xenvif_gop_frag_copy_grant(unsigned long gfn,
+				       unsigned offset,
+				       unsigned int len,
+				       void *data)
+{
+	unsigned int bytes;
+
+	while (len) {
+		bytes = len;
+		xenvif_setup_copy_gop(gfn, offset, &bytes, data);
+		offset += bytes;
+		len -= bytes;
+	}
+}
+
 /*
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
@@ -283,83 +357,52 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
 				 struct page *page, unsigned long size,
 				 unsigned long offset, int *head)
 {
-	struct gnttab_copy *copy_gop;
-	struct xenvif_rx_meta *meta;
+	struct gop_frag_copy info = {
+		.queue = queue,
+		.npo = npo,
+		.head = *head,
+		.gso_type = XEN_NETIF_GSO_TYPE_NONE,
+	};
 	unsigned long bytes;
-	int gso_type = XEN_NETIF_GSO_TYPE_NONE;
 
 	if (skb_is_gso(skb)) {
 		if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV4)
-			gso_type = XEN_NETIF_GSO_TYPE_TCPV4;
+			info.gso_type = XEN_NETIF_GSO_TYPE_TCPV4;
 		else if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
-			gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
+			info.gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
 	}
 
 	/* Data must not cross a page boundary. */
 	BUG_ON(size + offset > PAGE_SIZE<<compound_order(page));
 
-	meta = npo->meta + npo->meta_prod - 1;
+	info.meta = npo->meta + npo->meta_prod - 1;
 
 	/* Skip unused frames from start of page */
 	page += offset >> PAGE_SHIFT;
 	offset &= ~PAGE_MASK;
 
 	while (size > 0) {
-		struct xen_page_foreign *foreign;
-
 		BUG_ON(offset >= PAGE_SIZE);
-		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
-
-		if (npo->copy_off == MAX_BUFFER_OFFSET)
-			meta = get_next_rx_buffer(queue, npo);
 
 		bytes = PAGE_SIZE - offset;
 		if (bytes > size)
 			bytes = size;
 
-		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
-			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
-
-		copy_gop = npo->copy + npo->copy_prod++;
-		copy_gop->flags = GNTCOPY_dest_gref;
-		copy_gop->len = bytes;
-
-		foreign = xen_page_foreign(page);
-		if (foreign) {
-			copy_gop->source.domid = foreign->domid;
-			copy_gop->source.u.ref = foreign->gref;
-			copy_gop->flags |= GNTCOPY_source_gref;
-		} else {
-			copy_gop->source.domid = DOMID_SELF;
-			copy_gop->source.u.gmfn =
-				virt_to_gfn(page_address(page));
-		}
-		copy_gop->source.offset = offset;
-
-		copy_gop->dest.domid = queue->vif->domid;
-		copy_gop->dest.offset = npo->copy_off;
-		copy_gop->dest.u.ref = npo->copy_gref;
-
-		npo->copy_off += bytes;
-		meta->size += bytes;
-
-		offset += bytes;
+		info.page = page;
+		gnttab_foreach_grant_in_range(page, offset, bytes,
+					      xenvif_gop_frag_copy_grant,
+					      &info);
 		size -= bytes;
+		offset = 0;
 
-		/* Next frame */
-		if (offset == PAGE_SIZE && size) {
+		/* Next page */
+		if (size) {
 			BUG_ON(!PageCompound(page));
 			page++;
-			offset = 0;
 		}
-
-		/* Leave a gap for the GSO descriptor. */
-		if (*head && ((1 << gso_type) & queue->vif->gso_mask))
-			queue->rx.req_cons++;
-
-		*head = 0; /* There must be something in this buffer now. */
-
 	}
+
+	*head = info.head;
 }
 
 /*
@@ -758,7 +801,7 @@ static int xenvif_count_requests(struct xenvif_queue *queue,
 		first->size -= txp->size;
 		slots++;
 
-		if (unlikely((txp->offset + txp->size) > PAGE_SIZE)) {
+		if (unlikely((txp->offset + txp->size) > XEN_PAGE_SIZE)) {
 			netdev_err(queue->vif->dev, "Cross page boundary, txp->offset: %u, size: %u\n",
 				 txp->offset, txp->size);
 			xenvif_fatal_tx_err(queue->vif);
@@ -1339,11 +1382,11 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
-		if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
+		if (unlikely((txreq.offset + txreq.size) > XEN_PAGE_SIZE)) {
 			netdev_err(queue->vif->dev,
 				   "txreq.offset: %u, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
-				   (unsigned long)(txreq.offset&~PAGE_MASK) + txreq.size);
+				   (unsigned long)(txreq.offset&~XEN_PAGE_MASK) + txreq.size);
 			xenvif_fatal_tx_err(queue->vif);
 			break;
 		}
@@ -1409,7 +1452,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
 			virt_to_gfn(skb->data);
 		queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
 		queue->tx_copy_ops[*copy_ops].dest.offset =
-			offset_in_page(skb->data);
+			offset_in_page(skb->data) & ~XEN_PAGE_MASK;
 
 		queue->tx_copy_ops[*copy_ops].len = data_len;
 		queue->tx_copy_ops[*copy_ops].flags = GNTCOPY_source_gref;
@@ -1894,7 +1937,7 @@ int xenvif_map_frontend_rings(struct xenvif_queue *queue,
 		goto err;
 
 	txs = (struct xen_netif_tx_sring *)addr;
-	BACK_RING_INIT(&queue->tx, txs, PAGE_SIZE);
+	BACK_RING_INIT(&queue->tx, txs, XEN_PAGE_SIZE);
 
 	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(queue->vif),
 				     &rx_ring_ref, 1, &addr);
@@ -1902,7 +1945,7 @@ int xenvif_map_frontend_rings(struct xenvif_queue *queue,
 		goto err;
 
 	rxs = (struct xen_netif_rx_sring *)addr;
-	BACK_RING_INIT(&queue->rx, rxs, PAGE_SIZE);
+	BACK_RING_INIT(&queue->rx, rxs, XEN_PAGE_SIZE);
 
 	return 0;
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236197

FromMark Rutland <mark.rutland@arm.com>
Date2015-09-30 13:40 +0200
Message-ID<qenTQ-3J6-19@gated-at.bofh.it>
In reply to#1236132
On Wed, Sep 30, 2015 at 11:45:15AM +0100, Julien Grall wrote:
> Hi all,

Hi,

> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
> 
> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
> guest crash.
> 
> This series is a first attempt to allow those Linux running with the current
> hypercall interface and PV protocol.
> 
> This solution has been chosen because we want to run Linux 64KB in released
> Xen ARM version or/and platform using an old version of Linux DOM0.

Just to check, would this be expected to work with a 16K DomU (e.g.
[2])?

From a quick scan it looks like the relaxations provided by this series
should work so long as PAGE_SIZE % XEN_PAGE_SIZE == 0, assuming I
haven't missed something.

> There is room for improvement, such as support of 64KB grant, modification
> of PV protocol to support different page size... They will be explored in a
> separate patch series later.
> 
> TODO list:
>     - Convert xenfb to 64KB
>     - Support for multiple page ring support
>     - Support for 64KB in gnttdev
>     - Support of non-indirect grant with 64KB frontend (patch sent [1])
>     - It may be possible to move some common define between
>     netback/netfront and blkfront/blkback in an header

Would any of these require more work to also handle 16K?

Thanks,
Mark.

[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/370117.html

> I've got most of the patches for the TODO items. I'm planning to send them as
> a follow-up as it's not a requirement for a basic guests.
> 
> All patches has been built tested for ARM32, ARM64, x86. But I haven't tested
> to run it on x86 as I don't have a box with Xen x86 running. Although, 99%
> of the changes has been made in the PV drivers there should be no specific
> issue. Although, I would be happy if someone give a try and see possible
> regression for x86.
> 
> I know that Konrad as a test-suite for x86. Konrand, would it be possible to
> give a run to for this series?
> 
> A branch based on the latest xentip/for-linus-4.4 can be found here:
> 
> git://xenbits.xen.org/people/julieng/linux-arm.git branch xen-64k-v5
> 
> There is no major changes in this series, only a couple of conflict during
> rebase in netback and balloon drivers. For those pathces, I've keept the
> reviewed-by/acked-by from Wei and Stefano. Let me know if it's not fine.
> 
> I also fold the swiotlb patch series into this series because it has been
> reviewed by Stefano and I don't think there is much controversy (see patch #21
> and #22).
> 
> Comments, suggestions are welcomed.
> 
> Sincerely yours,
> 
> [1] https://lkml.org/lkml/2015/9/11/567
> 
> Cc: david.vrabel@citrix.com
> Cc: konrad.wilk@oracle.com
> Cc: boris.ostrovsky@oracle.com
> Cc: wei.liu2@citrix.com
> Cc: roger.pau@citrix.com
> 
> Status of each patch:
> 
> A: Reviewed-by - Acked-by
> M: Patch modified in this series
> m: Minor changes in this series due to conflict during rebase
> L: Missing Acked-by from a Linux maintainers (Boris, David or Konrad)
> 
> Julien Grall (22):
> A       net/xen-netback: xenvif_gop_frag_copy: move GSO check out of the loop
> A       arm/xen: Drop pte_mfn and mfn_pte
> A   L   xen: Add Xen specific page definition
> A       xen/grant: Introduce helpers to split a page into grant
> A       xen/grant: Add helper gnttab_page_grant_foreign_access_ref_one
> A       block/xen-blkfront: Split blkif_queue_request in 2
> A       block/xen-blkfront: Store a page rather a pfn in the grant structure
> A       block/xen-blkfront: split get_grant in 2
> A   L   xen/biomerge: Don't allow biovec's to be merged when Linux is not
>           using 4KB pages
> A       xen/xenbus: Use Xen page definition
> A   L   tty/hvc: xen: Use xen page definition
> A m L   xen/balloon: Don't rely on the page granularity is the same for Xen
>           and Linux
> A       xen/events: fifo: Make it running on 64KB granularity
> A       xen/grant-table: Make it running on 64KB granularity
> A       block/xen-blkfront: Make it running on 64KB page granularity
> A       block/xen-blkback: Make it running on 64KB page granularity
> A       net/xen-netfront: Make it running on 64KB page granularity
> A m     net/xen-netback: Make it running on 64KB page granularity
> A       xen/privcmd: Add support for Linux 64KB page granularity
> A       arm/xen: Add support for 64KB page granularity
> A m L   xen/swiotlb: Pass addresses rather than frame numbers to
>           xen_arch_need_swiotlb
> A   L   xen/swiotlb: Add support for 64KB page granularity
> 
>  arch/arm/include/asm/xen/page-coherent.h |  26 +-
>  arch/arm/include/asm/xen/page.h          |  22 +-
>  arch/arm/xen/enlighten.c                 |   6 +-
>  arch/arm/xen/mm.c                        |  39 ++-
>  arch/arm/xen/p2m.c                       |   6 +-
>  arch/x86/include/asm/xen/page.h          |   6 +-
>  drivers/block/xen-blkback/blkback.c      |   5 +-
>  drivers/block/xen-blkback/common.h       |  17 +-
>  drivers/block/xen-blkback/xenbus.c       |   9 +-
>  drivers/block/xen-blkfront.c             | 552 ++++++++++++++++++++-----------
>  drivers/net/xen-netback/common.h         |  16 +-
>  drivers/net/xen-netback/netback.c        | 167 ++++++----
>  drivers/net/xen-netfront.c               | 122 +++++--
>  drivers/tty/hvc/hvc_xen.c                |   4 +-
>  drivers/xen/balloon.c                    |  69 +++-
>  drivers/xen/biomerge.c                   |   8 +
>  drivers/xen/events/events_base.c         |   2 +-
>  drivers/xen/events/events_fifo.c         |   2 +-
>  drivers/xen/grant-table.c                |  32 +-
>  drivers/xen/privcmd.c                    |   8 +-
>  drivers/xen/swiotlb-xen.c                |  43 ++-
>  drivers/xen/xenbus/xenbus_client.c       |   6 +-
>  drivers/xen/xenbus/xenbus_probe.c        |   3 +-
>  drivers/xen/xlate_mmu.c                  | 124 ++++---
>  include/xen/grant_table.h                |  51 +++
>  include/xen/page.h                       |  27 +-
>  26 files changed, 937 insertions(+), 435 deletions(-)
> 
> -- 
> 2.1.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236205

FromJulien Grall <julien.grall@citrix.com>
Date2015-09-30 13:50 +0200
Message-ID<qeo3w-3UA-3@gated-at.bofh.it>
In reply to#1236197
On 30/09/15 12:32, Mark Rutland wrote:
> On Wed, Sep 30, 2015 at 11:45:15AM +0100, Julien Grall wrote:
>> Hi all,
> 
> Hi,
> 
>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>> hypercall interface and PV protocol are always based on 4KB page granularity.
>>
>> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
>> guest crash.
>>
>> This series is a first attempt to allow those Linux running with the current
>> hypercall interface and PV protocol.
>>
>> This solution has been chosen because we want to run Linux 64KB in released
>> Xen ARM version or/and platform using an old version of Linux DOM0.
> 
> Just to check, would this be expected to work with a 16K DomU (e.g.
> [2])?
> 
> From a quick scan it looks like the relaxations provided by this series
> should work so long as PAGE_SIZE % XEN_PAGE_SIZE == 0, assuming I
> haven't missed something.

Correct, this series is able to cope with any PAGE_SIZE as long as it's
a multiple of the granularity used by Xen (i.e 4KB on ARM).

>> There is room for improvement, such as support of 64KB grant, modification
>> of PV protocol to support different page size... They will be explored in a
>> separate patch series later.
>>
>> TODO list:
>>     - Convert xenfb to 64KB
>>     - Support for multiple page ring support
>>     - Support for 64KB in gnttdev
>>     - Support of non-indirect grant with 64KB frontend (patch sent [1])
>>     - It may be possible to move some common define between
>>     netback/netfront and blkfront/blkback in an header
> 
> Would any of these require more work to also handle 16K?

No. It should just boot on Xen as long as the CPU is support 16K
granularity.

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236272

FromMark Rutland <mark.rutland@arm.com>
Date2015-09-30 15:10 +0200
Message-ID<qepiW-5S4-9@gated-at.bofh.it>
In reply to#1236205
> > Just to check, would this be expected to work with a 16K DomU (e.g.
> > [2])?
> > 
> > From a quick scan it looks like the relaxations provided by this series
> > should work so long as PAGE_SIZE % XEN_PAGE_SIZE == 0, assuming I
> > haven't missed something.
> 
> Correct, this series is able to cope with any PAGE_SIZE as long as it's
> a multiple of the granularity used by Xen (i.e 4KB on ARM).

[...]

> > Would any of these require more work to also handle 16K?
> 
> No. It should just boot on Xen as long as the CPU is support 16K
> granularity.

Great to hear, thanks!

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237502 — Re: [Xen-devel] [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux

FromDavid Vrabel <david.vrabel@citrix.com>
Date2015-10-01 17:20 +0200
SubjectRe: [Xen-devel] [PATCH v5 00/22] xen/arm64: Add support for 64KB page in Linux
Message-ID<qeNOj-8mD-27@gated-at.bofh.it>
In reply to#1236132
On 30/09/15 11:45, Julien Grall wrote:
> Hi all,
> 
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
> 
> Any attempt to boot a Linux guest with 64KB pages enabled will result to a
> guest crash.
> 
> This series is a first attempt to allow those Linux running with the current
> hypercall interface and PV protocol.
> 
> This solution has been chosen because we want to run Linux 64KB in released
> Xen ARM version or/and platform using an old version of Linux DOM0.

Applied to for-linus-4.4, thanks.

Boris, can you kick off a set of tests for this branch, please?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web