WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: mem-event interface

To: Patrick Colp <pjcolp@xxxxxxxxx>, Grzegorz Milos <grzegorz.milos@xxxxxxxxx>
Subject: RE: [Xen-devel] Re: mem-event interface
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Sun, 27 Jun 2010 20:12:47 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Bryan D. Payne" <bryan@xxxxxxxxxxxx>, Andrew Peace <Andrew.Peace@xxxxxxxxxxxxx>, Steven Hand <Steven.Hand@xxxxxxxxxxxxx>
Delivery-date: Sun, 27 Jun 2010 20:14:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTillp-tfN2doCCSG_v3twBjMIAyzxdBgHNnYfF0n@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTikydcTHLFmPNx_5kTsSYq7BM_u_l54tB3f3H_iT@xxxxxxxxxxxxxx> <AANLkTilKT2LoowaY_7RB-hKTTUMkhC_lLTohmohozKeH@xxxxxxxxxxxxxx> <AANLkTikTBCAj9gCM-Ksk2f85tGfySKfqcdI7Ojy9LU30@xxxxxxxxxxxxxx> <AANLkTimNnlittGra6kk3VWvDcWIRdw2HRBWnb3b2l3R-@xxxxxxxxxxxxxx> <AANLkTinwajCCxk8LtzfR6CwBqk-FZP4HvmsxMEHWthdn@xxxxxxxxxxxxxx> <AANLkTilJp4OPyG07RFpqYjIVclkaqXIWEG-ZUU_CNJTU@xxxxxxxxxxxxxx> <AANLkTinJ736hCNDhYDeZBZTTuMwKH8x265NoWVPYoco9@xxxxxxxxxxxxxx> <AANLkTim5L3NleKd71V_rihMXwYQnTIDdgBSpCIuJRXnW@xxxxxxxxxxxxxx> <AANLkTik0dlCjyh4nk7goM4V7uTv6j5yLwzF6OdhVI4-h@xxxxxxxxxxxxxx> <AANLkTikgLaQA95ocrMcSOCBWQbPfrRLPua0sS6F9mL44@xxxxxxxxxxxxxx> <20100624091811.GC31695@xxxxxxxxxxxxxxxxxxxxxxx> <AANLkTikJSCCdKt0YvePT1gA9rx2CTahpsRNKYNv6jB7s@xxxxxxxxxxxxxx AANLkTillp-tfN2doCCSG_v3twBjMIAyzxdBgHNnYfF0n@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> 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