From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: 32-on-64: pvfb issue Date: Thu, 18 Jan 2007 16:00:35 +0100 Message-ID: <87wt3kz8fg.fsf@pike.pond.sub.org> References: <45AF7CDD.6090709@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <45AF7CDD.6090709@suse.de> (Gerd Hoffmann's message of "Thu, 18 Jan 2007 14:57:49 +0100") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Hoffmann Cc: Xen devel list List-Id: xen-devel@lists.xenproject.org Gerd Hoffmann writes: > Hi, > > There is a problem with the virtual framebuffer: The page directory in > the shared page (xenfb_page->pd[]) is unsigned long and thus has > different sizes on 32bit and 64bit. The alignment is different too. And > on top of that the frontend driver doesn't clear the shared page, which > makes it difficult to autodetect the bitsize. I've tried nevertheless, > patch (untested!) attached for comments. In the long run this code is > supposed to be replaced by grant tables anyway, so it is probably okay > to live with the hack for the time being. We could of course also fix > the struct if we can afford breaking the interface. As it is quite new > and probably (hmm, does fc6 ship it?) not widely used yet that might be > an option. Breaking the API now is right out of the question, I fear :) You can evolve the API. Let the frontend put something in xenstore[*] that lets the backend detect which page layout to use. Make sure the backend can deal with old and new frontend. I doubt it's worthwhile here. Excuse my ignorance, but why do you have to guess the guest's size? Doesn't dom0 know? [*] I suggested to put version ID right into the page, but that was shot down in favor of xenstore.