|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)
Pat Campbell <plc@xxxxxxxxxx> writes:
> Markus Armbruster wrote:
[...]
>> 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.
Every slot in pd[] gets us 2M (64 bit). The shared page has space
left for about 500 slots. We can easily increase pd[] to 256 slots,
good for 512M of framebuffer, or 128 Megapixels (>12000x10000), *and*
leave plenty of space in the shared page for future uses.
The backend should map precisely as much framebuffer as the frontend
tells it (struct xenfb_page member mem_length), using as much of pd[]
as necessary for that.
> 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?
I haven't reviewed your patch in detail. The change in fb mapping
stuck out, and I wanted it discussed before I do that. Assuming we
can agree to extending pd[] instead, would you mind preparing a new
patch for us to review?
[...]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|