On Fri, 2011-01-07 at 16:12 +0000, dgdegra@xxxxxxxxxxxxx wrote:
> @@ -556,17 +552,58 @@ static unsigned long vmalloc_to_mfn(void *address)
> return pfn_to_mfn(vmalloc_to_pfn(address));
> }
>
> -static void xenfb_init_shared_page(struct xenfb_info *info,
> +static void xenfb_init_shared_page(struct xenbus_device *dev,
> + struct xenfb_info *info,
> struct fb_info *fb_info)
> {
> - int i;
> int epd = PAGE_SIZE / sizeof(info->mfns[0]);
> + int be_id = dev->otherend_id;
> + int i, ref;
> + unsigned long mfn;
> + grant_ref_t gref_head;
> + int allpages = info->nr_pages + ((info->nr_pages + epd - 1) / epd) + 1;
> +
> + int grants = 0;
> + xenbus_scanf(XBT_NIL, dev->otherend, "use-grants", "%d", &grants);
There doesn't seem to be any negotiation with the backend about whether
or not grants should be used so there is no way for a backend to know if
it can choose to set this flag or not, granted not all backends will
have a choice due to their privilege level.
More importantly there is also no way for the backend to figure out is
the frontend is going to obey the request if it does write it (at least
until it tries to map a gref and fails because its really got an mfn).
Usually both front and backend would write a feature-foo node to their
respective directory in xenstore and then figure out what to do based on
what the other end wrote.
In the kbdfront patch you simply write both the mfn and the grant
reference to xenstore, presumably the backend then just picks for itself
which access method to use, could that approach be applicable here?
There seems to be slack in xenfb_page which could accommodate a second
pd array containing grefs for the pages. The presence of a page-gref
node in xenstore would indicate that the larger structure with the grefs
is in use.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home