From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Gorm Hansen Subject: Re: Forwarding page faults from within Xen Date: Mon, 22 Mar 2004 13:01:16 +0100 Sender: xen-devel-admin@lists.sourceforge.net Message-ID: <1079956876.908.33.camel@paleface> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Keir Fraser Cc: Xen list List-Id: xen-devel@lists.xenproject.org On Mon, 2004-03-22 at 12:51, Keir Fraser wrote: > > hi, > > > Well, you need *some* way of executing and informing the domain to > tell it about the fault. So there has to be *some* pinned > always-accessible memory to be able to do this. If you get rid of this > constraint on the guest-OS stack, then you'll still need some other > memory buffer to store fault info -- there has to be some back > stop. So I don't think you save yourself any pain. Hmm, I suppose you are right about that then... I keep forgetting the price all the luxury features of L4 came at. > As for network buffers, how would we present the fault to the guest > OS? The neatest answer to all this that I can see is to use shadow > page tables and use this to get Xen to log pages as they are dirtied. > Anything which involves the guest OS itself receiving 'page faults' > for events which occurred under its feet just sounds hideous to me! > :-) Actually, my problem is not as much the network buffer pages, put the pagetables pointing to them. Right now I identify these and take care of them specially so that my checkpoint is consistent, but it is a bit unclear to me what happens if I write-protect them. Will Xen kill me, or just silently change the protection bits? Jacob ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click