From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: RFC: [0/2] Remove netloop by lazy copying in netback Date: Tue, 27 Mar 2007 10:58:46 +0100 Message-ID: References: <20070327092028.GA25077@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070327092028.GA25077@gondor.apana.org.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Herbert Xu Cc: Isaku Yamahata , Xen Development Mailing List List-Id: xen-devel@lists.xenproject.org On 27/3/07 10:20, "Herbert Xu" wrote: >> That's not quite how Jose's patch works. The lazy mapping is done by the >> guest in his patch. > > That would mean the breaking of large pages on ia64 or any other > platform that uses them. Is there any benefit for not doing it > in the hypervisor? Yet another bloody grant-table hypercall! Also there's the question of where this lazy state gets squirrelled away until the demand mapping occurs. Perhaps the p2m is usable in this case, since I expect we have plenty of spare bits for a not-present entry... But anyway, we don't have the luxury of a p2m to stick things in the x86 case. >> If we're not going to go as far as supporting guest-visible 'p2m faults' >> then I think overall your original patch is probably the best approach so >> far. If I view the new hypercall as a special case of the existing unmap >> (which is an unmap-to-zero-pte special case) then it's not so bad. At least >> there should be very little new code in the hypervisor needed to implement >> it. We have a little while longer to think about this since the patches >> aren't for 3.0.5. > > OK. How do you want to proceed from here then? I'll take a closer look at your original patch. Having viewed the alternatives I don't hate it so much now. :-) -- Keir