[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Re: mem-event interface
> From: Patrick Colp [mailto:pjcolp@xxxxxxxxx] > Sent: Sunday, June 27, 2010 11:40 AM > To: Grzegorz Milos > Cc: Xen-Devel (E-mail); Tim Deegan; George Dunlap; Bryan D. Payne; > Andrew Peace; Steven Hand > Subject: Re: [Xen-devel] Re: mem-event interface > > On 27 June 2010 08:45, Grzegorz Milos <grzegorz.milos@xxxxxxxxx> wrote: > >> I agree that multiple rings are a good idea here - especially if we > want > >> to disaggregate and have event handlers in multiple domains. > >> > >> Maybe the ring-registering interface could take a type and a > rangeset - > >> that would reduce the amount of extra chatter at the cost of some > more > >> overhead in Xen. > >> > > > > Well, the trouble is what do units you express the ranges in. In pfns > > belonging to a given guest, or in mfns? Either way memory sharing > > would use <0 - max_{p,m}fn> rangeset most of the time. Similarly for > > teh pager (I believe). Bryan, could you comment on XenAccess? I guess > > rangesets would be useful there the most. > > > > I certainly agree that we will have to swallow some complexity in > Xen, > > to make the interface efficient. Some filters will have to live in > > Xen, in order not to generate unnecessarily large rate of no-op > > events. > > I suppose one way to handle the range is to specify the range in terms > of full address (i.e. not pfn, so page 0xf would be specified as > 0xf000). This way, we can specify the full range of memory (e.g. > <0xf000, 0xf001> to watch the first byte of the page with pfn 0xf). > However, it might be useful to have a flag that lets you specify if > you mean pfns, mfns, or full address ranges (or something of the > like). Xen should return some sort of unique identifier for each > handler so that new ranges can easily be added/removed dynamically. Probably a good idea to plan for page sizes different from 4K anyway. I wouldn't be surprised if a 2M-pagesize-only Xen exists in the not-too-distant future. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |