All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@suse.de>
To: Gerd Hoffmann <kraxel@suse.de>
Cc: Xen devel list <xen-devel@lists.xensource.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: 32-on-64: pvfb issue
Date: Thu, 18 Jan 2007 17:55:58 +0100	[thread overview]
Message-ID: <45AFA69E.1000206@suse.de> (raw)
In-Reply-To: <45AFA178.7000206@suse.de>

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

  Hi,

> Hmm, assuming we'll fix up the ABI now to be binary compatible between
> 32 and 64 bit and put that one into both 3.0.4 and unstable, could that
> still make it into RHEL-5 or is that too late now?

i.e. something along the lines of the attached patch (compile tested
only) ...

cheers,
  Gerd

[-- Attachment #2: abi-fb --]
[-- Type: text/plain, Size: 3713 bytes --]

--- build-32-unstable-13401/linux-2.6-xen-sparse/drivers/xen/fbfront/xenfb.c.abi	2007-01-18 17:43:07.000000000 +0100
+++ build-32-unstable-13401/linux-2.6-xen-sparse/drivers/xen/fbfront/xenfb.c	2007-01-18 17:46:29.000000000 +0100
@@ -58,7 +58,7 @@
 
 	int			irq;
 	struct xenfb_page	*page;
-	unsigned long 		*mfns;
+	u64                     *mfns;
 	int			update_wanted; /* XENFB_TYPE_UPDATE wanted */
 
 	struct xenbus_device	*xbdev;
@@ -474,12 +474,12 @@
 	if (info->pages == NULL)
 		goto error_nomem;
 
-	info->mfns = vmalloc(sizeof(unsigned long) * info->nr_pages);
+	info->mfns = vmalloc(sizeof(u64) * info->nr_pages);
 	if (!info->mfns)
 		goto error_nomem;
 
 	/* set up shared page */
-	info->page = (void *)__get_free_page(GFP_KERNEL);
+	info->page = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
 	if (!info->page)
 		goto error_nomem;
 
@@ -600,6 +600,7 @@
 	for (i = 0; i < info->nr_pages; i++)
 		info->mfns[i] = vmalloc_to_mfn(info->fb + i * PAGE_SIZE);
 
+	info->page->protocol = 1;
 	info->page->pd[0] = vmalloc_to_mfn(info->mfns);
 	info->page->pd[1] = 0;
 	info->page->width = XENFB_WIDTH;
--- build-32-unstable-13401/tools/xenfb/xenfb.c.abi	2007-01-18 17:48:57.000000000 +0100
+++ build-32-unstable-13401/tools/xenfb/xenfb.c	2007-01-18 17:50:40.000000000 +0100
@@ -329,12 +329,20 @@
 	struct xenfb_page *page = xenfb->fb.page;
 	int n_fbmfns;
 	int n_fbdirs;
+	unsigned long pgmfns[2];
 	unsigned long *fbmfns;
+	uint64_t *ptr64;
+	int i;
+
+	ptr64 = page->pd;
 
 	n_fbmfns = (xenfb->fb_len + (XC_PAGE_SIZE - 1)) / XC_PAGE_SIZE;
-	n_fbdirs = n_fbmfns * sizeof(unsigned long);
+	n_fbdirs = n_fbmfns * sizeof(uint64_t);
 	n_fbdirs = (n_fbdirs + (XC_PAGE_SIZE - 1)) / XC_PAGE_SIZE;
 
+	for (i = 0; i < n_fbdirs; i++)
+		pgmfns[i] = ptr64[i];
+
 	/*
 	 * Bug alert: xc_map_foreign_batch() can fail partly and
 	 * return a non-null value.  This is a design flaw.  When it
@@ -342,18 +350,23 @@
 	 * access.
 	 */
 	fbmfns = xc_map_foreign_batch(xenfb->xc, domid,
-			PROT_READ, page->pd, n_fbdirs);
+			PROT_READ, pgmfns, n_fbdirs);
 	if (fbmfns == NULL)
 		return -1;
 
+	ptr64 = (void*)fbmfns;
+	fbmfns = malloc(n_fbmfns * sizeof(*fbmfns));
+	for (i = 0; i < n_fbmfns; i++)
+		fbmfns[i] = ptr64[i];
+	munmap(ptr64, n_fbdirs * XC_PAGE_SIZE);
+
 	xenfb->pub.pixels = xc_map_foreign_batch(xenfb->xc, domid,
 				PROT_READ | PROT_WRITE, fbmfns, n_fbmfns);
-	if (xenfb->pub.pixels == NULL) {
-		munmap(fbmfns, n_fbdirs * XC_PAGE_SIZE);
+	if (xenfb->pub.pixels == NULL)
 		return -1;
-	}
 
-	return munmap(fbmfns, n_fbdirs * XC_PAGE_SIZE);
+	free(fbmfns);
+	return 0;
 }
 
 static int xenfb_bind(struct xenfb_device *dev)
--- build-32-unstable-13401/xen/include/public/io/fbif.h.abi	2007-01-18 17:34:49.000000000 +0100
+++ build-32-unstable-13401/xen/include/public/io/fbif.h	2007-01-18 17:38:39.000000000 +0100
@@ -102,6 +102,8 @@
     uint32_t line_length;   /* the length of a row of pixels (in bytes) */
     uint32_t mem_length;    /* the length of the framebuffer (in bytes) */
     uint8_t depth;          /* the depth of a pixel (in bits) */
+    uint8_t protocol;       /* protocol version, will bump when we switch to grant tables */
+    uint8_t pad[6];         /* align next field to 64bit */
 
     /*
      * Framebuffer page directory
@@ -109,10 +111,10 @@
      * Each directory page holds PAGE_SIZE / sizeof(*pd)
      * framebuffer pages, and can thus map up to PAGE_SIZE *
      * PAGE_SIZE / sizeof(*pd) bytes.  With PAGE_SIZE == 4096 and
-     * sizeof(unsigned long) == 4, that's 4 Megs.  Two directory
+     * sizeof(uint64_t) == 8, that's 2 Megs.  Four directory
      * pages should be enough for a while.
      */
-    unsigned long pd[2];
+    uint64_t pd[4];
 };
 
 /*

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

  reply	other threads:[~2007-01-18 16:55 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-18 13:57 32-on-64: pvfb issue Gerd Hoffmann
2007-01-18 14:07 ` Keir Fraser
2007-01-18 15:00 ` Markus Armbruster
2007-01-18 15:35   ` Gerd Hoffmann
2007-01-18 15:53     ` Daniel P. Berrange
2007-01-18 16:34       ` Gerd Hoffmann
2007-01-18 16:55         ` Gerd Hoffmann [this message]
2007-01-18 17:05         ` Daniel P. Berrange
2007-01-18 18:31     ` Keir Fraser
2007-01-19  9:46       ` Gerd Hoffmann
2007-01-19  9:54       ` Gerd Hoffmann
2007-01-19 10:31         ` Markus Armbruster
2007-01-19 10:46           ` Gerd Hoffmann
2007-01-19 11:53             ` Markus Armbruster
2007-01-19 11:10         ` Keir Fraser
2007-01-19 11:43           ` Gerd Hoffmann
2007-01-19 12:01             ` Keir Fraser
2007-01-19 12:59               ` Gerd Hoffmann
2007-01-19 13:45                 ` Keir Fraser
2007-01-19 15:08                   ` Gerd Hoffmann
2007-01-19 15:22                     ` Keir Fraser
2007-01-19 15:31                       ` Gerd Hoffmann
2007-01-19 16:05                         ` Keir Fraser
2007-01-20  0:09                           ` [Patch] [VTPM_TOOLS] Add HVM support to vtpm_manager Scarlata, Vincent R
2007-01-22  7:50                           ` 32-on-64: pvfb issue Gerd Hoffmann
2007-01-22 14:01                             ` Gerd Hoffmann
2007-01-22 14:48                               ` Keir Fraser
2007-01-23 12:53                                 ` Gerd Hoffmann
2007-01-23 15:07                                   ` Keir Fraser
2007-01-23 15:56                                     ` Gerd Hoffmann
2007-01-24 11:23                                   ` Gerd Hoffmann
2007-01-24 12:02                                     ` Keir Fraser
2007-01-24 12:24                                     ` Markus Armbruster
2007-01-24 12:38                                       ` Gerd Hoffmann
2007-01-24 14:24                                         ` Markus Armbruster
2007-01-24 15:25                                           ` Gerd Hoffmann
2007-01-25 13:16                                   ` 32-on-64 broken in unstable Gerd Hoffmann
2007-01-25 13:25                                     ` Keir Fraser
2007-01-25 13:34                                       ` Gerd Hoffmann
2007-01-22 15:22                               ` 32-on-64: pvfb issue Markus Armbruster
2007-01-22 15:33                                 ` Gerd Hoffmann
2007-01-22 15:40                                   ` Keir Fraser
2007-01-19 16:06                         ` Markus Armbruster
2007-01-22  7:56                           ` Gerd Hoffmann
2007-01-19 10:43       ` Ian Campbell
2007-01-19 12:03         ` Markus Armbruster
2007-01-22 18:32       ` Does vt-x itself have perf. impact on Hypervisor w/o considering HVM? Liang Yang
2007-01-23 10:05         ` [Xen-users] " Petersson, Mats
2007-01-23 16:15           ` Liang Yang
2007-01-23 16:33             ` Petersson, Mats

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45AFA69E.1000206@suse.de \
    --to=kraxel@suse.de \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.