[Xen-devel] Re: mem-event interface

[Grzegorz Milos <grzegorz.milos@xxxxxxxxx>]

[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