From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: netback: Delayed copy alternative Date: Wed, 13 Nov 2013 20:29:58 +0000 Message-ID: <5283E146.5000604@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vgh4d-0005nX-Ox for xen-devel@lists.xenproject.org; Wed, 13 Nov 2013 20:30:09 +0000 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen-devel@lists.xenproject.org" , Ian Campbell , Wei Liu , Paul Durrant , Malcolm Crossley , David Vrabel Cc: Jonathan Davies List-Id: xen-devel@lists.xenproject.org Hi, I'm trying to forward port delayed copy to my new grant mapping patches. One important problem I've faced is that classic used gnttab_copy_grant_page to replace the granted page with a local copy and unmap the grant. And this function has never been upstreamed as only netback used it. Unfortunately upstreaming it is not a very easy task, as the kernel's grant table infrastructure doesn't track at the moment whether the page is DMA mapped or not. It is required because we shouldn't proceed with the copy and replace if a device already mapped the page for DMA. David came up with an alternative idea: we do this delayed copy because we don't want the guest's page to get stucked in Dom0 indefinitely. The only realistic case for that would be if the egress interface would be an another guest's vif, where the guest (either due to a bug or as a malicious attempt) doesn't empty its ring. I think it's a safe assumption that Dom0 otherwise doesn't hold on to packets for too long. Or if it does, then that's a bug we should fix instead of doing a copy of the packet. If we accept that only other vif's can keep the skb indefinitely, then an easier solution would be to handle this problem on the RX side: the RX thread can also check whether this skb hanged around for too long and drop it. Actually, xenvif_start_xmit already checks if the guest provided enough slots for us to do the grant copy. If I understand it correctly. What do you think about such an approach? Regards, Zoli