| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: userspace block backend / gntdev problems
Keir Fraser wrote:
> On 26/1/08 08:41, "Markus Armbruster" <armbru@xxxxxxxxxx> wrote:
>
>
>>> In my latest post on "Dynamic modes support for PV xenfb" I am using
>>> grants to map an extended framebuffer. I have a single grant ref that
>>> points to 10 other refs. The other refs contain MFNs. Same technique as
>>> the current framebuffer pd array but avoids the 64bit long issue. Kind
>>> of a hybrid approach. I am able to map a 22MB framebuffer when running a
>>> 64 bit guest and 44MB when running a 32 bit guest. When the backend is
>>> done with the mapping it sends a message to the frontend to free up the
>>> refs.
>>>
>> Uhm, I fear I didn't get the advantage of your hybrid approach. Could
>> you explain?
>>
>
> Presumably it allows creation of huge framebuffers without using up lots of
> grants, or slots in accounting tables that Xen maintains. Given that those
> tables can dynamically grow, I'm not sure how useful the two-level grant
> table would be.
>
> -- Keir
>
>
>
Well, turns out my email did not really get sent. Keir is right, it is
a two level grant table. Solution might not be useful in the general
case but for this device I think it fits the bill. Existing xenfb code
is already doing a two level table which has to be maintained for
backward compatibility reasons, might as well be consistent. Also by
using a two level grant table we don't have to extend the event
structure which might be a compatibility issue.
I will get my patches sent up for your review directly.
Pat
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home