[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/mm: Improve ring management for memory events. Do not lose guest events
> On Fri, Jan 13, Andres Lagar-Cavilla wrote: > >> > p2m_mem_paging_drop_page() should remain void because the caller has >> > already done its work, making it not restartable. Also it is only >> called >> > when a gfn is in paging state, which I'm sure can not happen without a >> > ring. >> >> Well, the rationale is that returning an error code can only help, >> should >> new error conditions arise. Keep in mind that the pager and the ring can >> disappear at any time, so ENOSYS can still happen. > > The ring should rather not disappear at all until ->paged_pages drops to > zero. Unless the goal is a restartable pager, > XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when > ->pages_pages is not zero. Then the checks in drop_page and populate can > be relaxed. Well, there are two separate things here. Should drop return an error code? No harm in that. Then there is your point about the ring not going away if ->paged_pages is nonzero. Which I like, but is currently not implemented, afaict. Separate patch I guess. > >> I'll refresh and add your signed-off-by to cover the portions of the >> work >> that originate from your end, is that ok? > > I havent finish the review yet, have to check how it may work with wait > queues in gfn_to_mfn*. Another case of "the two separate things" :) We definitely look forward to wait queue support for gfn_to_mfn*. But that's a separate consumer of the wait queue feature. Are you worried that this patch might break your gfn_to_mfn* strategy? We did base it on your work. Thanks, Andres > > Olaf > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |