|
xen-devel
[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
|
|
|
Home