[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: mem-event interface
[From Patrick] I think the idea of multiple rings is a good one. We'll register the clients in Xen and when an mem_event is reached, we can just iterate through the list of listeners to see who needs a notification. The person working on the anti-virus stuff is Bryan Payne from Georgia Tech. I've CCed him as well so we can get his input on this stuff as well. It's better to hash out a proper interface now rather than continually changing it around. Patrick On Wed, Jun 23, 2010 at 11:19 PM, Grzegorz Milos <grzegorz.milos@xxxxxxxxx> wrote: > [From Gregor] > > There are two major events that the memory sharing code needs to > communicate over the hypervisor/userspace boundary: > 1. GFN unsharing failed due to lack of memory. This will be called the > 'OOM event' from now on. > 2. MFN is no longer sharable (actually an opaque sharing handle would > be communicated instead of the MFN). 'Handle invalidate event' from > now on. > > The requirements on the OOM event are relatively similar to the > page-in event. The way this should operate is that the faulting VCPU > is paused, and the pager is requested to free up some memory. When it > does so, it should generate an appropriate response, and wake up the > VCPU back again using a domctl. The event is going to be low volume, > and since it is going to be handled synchronously, likely in tens of > ms, there are no particular requirements on the efficiency. > > Handle invalidate event type is less important in the short term > because the userspace sharing daemon is designed to be resilient to > unfresh sharing state. However, if it is missing it will make the > sharing progressively less effective as time goes on. The idea is that > the hypervisor communicates which sharing handles are no longer valid, > such that the sharing daemon only attempts to share pages in the > correct state. This would be relatively high volume event, but it > doesn't need to be accurate (i.e. events can be dropped if they are > not consumed quickly enough). As such this event should be batch > delivered, in an asynchronous fashion. > > The OOM event is coded up in Xen, but it will not be consumed properly > in the pager. If I remember correctly, I didn't want to interfere with > the page-in events because the event interface assumed that mem-event > responses are inserted onto the ring in precisely the same order as > the requests. This may not be the case when we start mixing different > event types. WRT to the handle invalidation, the relevant hooks exist > in Xen, and in the mem sharing daemon, but there is no way to > communicate events to two different consumers atm. > > Since the requirements on the two different sharing event types are > substantially different, I think it may be easier if separate channels > (i.e. separate rings) were used to transfer them. This would also fix > the multiple consumers issue relatively easily. Of course you may know > of some other mem events that wouldn't fit in that scheme. > > I remember that there was someone working on an external anti-virus > software, which prompted the whole mem-event work. I don't remember > his/hers name or affiliation (could you remind me?), but maybe he/she > would be interested in working on some of this? > > Thanks > Gregor > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |