[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
On Thu, Sep 20, 2012 at 02:12:25PM +0100, Oliver Chick wrote: > Thank you for all your useful feedback, Konrad. > > I have made most of the changes you suggest. I will test them and > repost. I have made a few points below. Great. Looking forward to your next patch. Also pls include it as an attachment as I could not apply it last time.. Not sure if that is something with your mailer - but attachments usually survive any MUA mangling. > > > + page_to_pfn(pers_gnt->page)); > > > > Would it make sense to cache this in the 'pers_gnt' structure? > > As far as I can tell, we only need this value when mapping, and > unmapping. So if we cache it, we will use it a maximum of one time. I > think it's cheap to calculate. Am I right? Then lets not cache it. > > > @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif > > > *blkif, > > > for (i = 0; i < nseg; i++) { > > > while ((bio == NULL) || > > > (bio_add_page(bio, > > > - blkbk->pending_page(pending_req, i), > > > > Can we get rid of pending_page macro? > > Unfortunately not, it is still used in the non-persistent mode to > populate the pages[]. Fair enough > > > + memcpy(shared_data + sg->offset, > > > + bvec_data + sg->offset, > > > + sg->length); > > > > Do we need to worry about it spilling over a page? Should we check that > > sg>offset + sg->length < PAGE_SIZE ? > > I agree, this is probably a worthwhile thing to check. > > > > > Also this would imply that based on the offset (so say it is 3999) that the > > old data (0->3998) > > might be still there - don't know how important that is? > > This is true. I spoke with IanC about this, and we *think* that this is > ok. Any old data that is there will have already been given to blkback, > so we're not really leaking data that we shouldn't be. Put a comment in saying that. In case in the future we want to share the persistent grants with other domains, we would need to address this. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |