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: Grzegorz Milos <grzegorz.milos@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: mem-event interface
From: Patrick Colp <pjcolp@xxxxxxxxx>
Date: Sun, 27 Jun 2010 10:40:17 -0700
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 10:40:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTikJSCCdKt0YvePT1gA9rx2CTahpsRNKYNv6jB7s@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.


Patrick

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel