From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pat Campbell Subject: Re: [RFC] Dynamic modes support for PV xenfb (included) Date: Wed, 30 Jan 2008 13:27:32 -0700 Message-ID: <47A0DDB4.20103@novell.com> References: <479D2669.5060105@novell.com> <87hcgv643k.fsf@pike.pond.sub.org> <47A07E7E.6040601@novell.com> <87sl0fxl5j.fsf@pike.pond.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87sl0fxl5j.fsf@pike.pond.sub.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Markus Armbruster Cc: "xen-devel@lists.xensource.com" , "Daniel P. Berrange" List-Id: xen-devel@lists.xenproject.org Markus Armbruster wrote: > Pat Campbell writes: > > >> Markus Armbruster wrote: >> >>> The current PVFB code shares the framebuffer as follows. The >>> framebuffer is described by a two level directory. The first level is >>> the page directory pd[] in the shared page. pd[] contains the mfns of >>> the second level directory pages. Those form an array containing the >>> mfns of the framebuffer. >>> >>> Your patch replaces both levels of the page directory by grants, but >>> not the framebuffer itself. What exactly does that buy us? >>> >>> >> Patch does not replace the pd array. That is still being used to >> maintain backwards compatibility. The required framebuffer memory is >> allocated in xenfb_probe() and is never reallocated or changed. Only >> the mapping to the framebuffer is changed. >> >> Maybe some pseudo code this will make it clearer. >> >> Frontend (FE) >> Determine framebuffer size >> Allocate framebuffer >> Fill in array of mfns >> Set shared page info to default mem length, width and height >> Fill in grant refs using array of mfns >> Back end Connected? >> Send map extended event (uses grant ref) >> Map extended done event? >> Free grant refs >> >> Backend (BE) >> Calculate number of mfns based on mem length from shared page >> Map in and point at framebuffer >> Map extended event? >> Map in using grant ref >> Change framebuffer pointer to the new location >> (still the same FE memory but now we can reach father >> into it) >> Send Map extended done >> >> At this point the Backend is still treating the framebuffer as >> 800x600x32 but does has access to the extended framebuffer memory but >> does not use it. When a resize event occurs the screen geometry changes >> but not the framebuffers mappings. >> > > Understood. > > >> So to answer what it buys us. It buys us access to a larger framebuffer >> for higher resolutions support. >> > > I can't see how using grants for the page directory is an improvement > over your previous iteration, which used pd[]. Can you explain? > I will try, I am not the greatest communicator lately. Previous iteration did use pd[] extending it to 3 from 2, this had the drawback of limiting our frame buffer size to a max of 6 MB for a 64 bit guest, 12mb for a 32 bit guest. 6MB can handle a maximum of 1280x1024 which in previous emails was deemed not enough. HD 1080 1920x1200 requires 9MB (pd[5], 64bit) WQXGA 2560x1600 requires 16MB (pd[8], 64bit) I could of just extended pd[] some more to increase the available slots but every time we want to increase the total frame buffer size we have to compile both ends. Probably could just keep reading/mapping until we hit a NULL in the backend to eliminate that issue but that ends adding any new items to the shared info page. By using grants: I don't effect the current shared info Don't have to deal with differences between a 64 bit long and a 32 bit long. Single grant ref fits within the event structure Are those benefits worth the code complexity that grants added? Not sure. Other than grants, which I can remove and revert to pd[], are all the other issues that were raised addressed? While I was working on this I "briefly" looked at the grant APIs to see how hard it would be to create a new API that allocates and claims a continuous block of references. If I had a guaranteed continuous block I would then only need to send the initial ref number and a count to the backend.