From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C49FC433F5 for ; Thu, 9 Sep 2021 02:06:43 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B664561108 for ; Thu, 9 Sep 2021 02:06:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B664561108 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:49014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mO9Sa-00036O-Eg for qemu-devel@archiver.kernel.org; Wed, 08 Sep 2021 22:06:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58148) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO9Rm-0002H1-Si for qemu-devel@nongnu.org; Wed, 08 Sep 2021 22:05:50 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:36780) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO9Rj-0003jS-7X for qemu-devel@nongnu.org; Wed, 08 Sep 2021 22:05:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631153144; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8HtotLq0nQZdGK43N1vNXa6d5L1VyHW9Y/D9Mo/3I5Q=; b=bKRRtyV/gVNZ1+DdzUYsRNMEGUHUoGjYmBF+6HsDm5QbHq34ue/HVVhRmy3enWJ4dTHQAw t1jupxIxHEJ/QdPyYbLb3F7hmJkh1FDsyDl6PXszjJ55O/EvLUUgva3spVQNEyDIoDi7Z5 I1u5uphHm8jCU9OWJ79VMXudlRAFFBg= Received: from mail-il1-f199.google.com (mail-il1-f199.google.com [209.85.166.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-139-9sb22fBmN3S_cPNVfxX8oA-1; Wed, 08 Sep 2021 22:05:43 -0400 X-MC-Unique: 9sb22fBmN3S_cPNVfxX8oA-1 Received: by mail-il1-f199.google.com with SMTP id f13-20020a056e02168d00b002244a6aa233so492438ila.7 for ; Wed, 08 Sep 2021 19:05:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=8HtotLq0nQZdGK43N1vNXa6d5L1VyHW9Y/D9Mo/3I5Q=; b=vfnHSg8yw8uQ3pT4cWUmzyDssv4D/g8gGPk8s35ld+GR7dfmvyA/EhfxuV9hoDVvsq FXIdQNlvDJZFt8SrzQDL8mclfp4gWWN26MskBnFR5gjLeR7jXvF4CWEEIYoYv9wV6iIo YtIrEoiIVLzHzWcmQ3hy/nWz5xSi0Xi9r7zscof2M3fXJjZrkRgpAlUSg158z7ax0HcU wt7HpamUYOWU7XUivC111NvmJZx9/8D9BUA+LBWXBCMcZlX7p8i7UFUCg5r6H+1h8gKy LnexM0jdBCinshTxn7tL7XVG9gtUX+l1UaNEIfJXCHM2lAZgy0ixopJQwpCe6ocogIh+ Of7g== X-Gm-Message-State: AOAM533BVMaJXK0EYt70VjNJTOk6EQTYVFS/9PgSIyjhacPtjsqYtjz+ ZRglPvcxeWiNheiSgzpBfSZb1rzI5xvLiE4B2c8Y5k5VLQtrCzMfMBTUtVEPVVSYxJswGPIyx43 RJDW3L3N5lCY3Jlc= X-Received: by 2002:a5e:db06:: with SMTP id q6mr532107iop.129.1631153143064; Wed, 08 Sep 2021 19:05:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxiesXsm/xAAs05Uyi7G42r2ZkFsy4el1jbMWmSF5LnvN4dQrgdYoTwsjL9ewHSlCuBEu2/A== X-Received: by 2002:a5e:db06:: with SMTP id q6mr532087iop.129.1631153142815; Wed, 08 Sep 2021 19:05:42 -0700 (PDT) Received: from xz-m1.local ([2607:fea8:56a3:500:f917:5e1f:6e63:74cd]) by smtp.gmail.com with ESMTPSA id d10sm199027ilu.54.2021.09.08.19.05.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Sep 2021 19:05:42 -0700 (PDT) Date: Wed, 8 Sep 2021 22:05:39 -0400 From: Peter Xu To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Subject: Re: [PATCH v1 2/3] io: Add zerocopy and errqueue Message-ID: References: MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=216.205.24.124; envelope-from=peterx@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.393, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Elena Ufimtseva , John G Johnson , Jagannathan Raman , qemu-block@nongnu.org, Juan Quintela , "Dr. David Alan Gilbert" , qemu-devel , Leonardo Bras Soares Passos , Paolo Bonzini , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Fam Zheng Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, Sep 08, 2021 at 10:57:06PM +0100, Daniel P. Berrangé wrote: > We think we're probably ok with migration as we are going to rely on the > face that we eventually pause the guest to stop page changes during the > final switchover. None the less I really strongly dislike the idea of > not honouring the kernel API contract, despite the potential performance > benefits it brings. Yes understandable, and it does looks tricky. But it's guest page and it's just by nature how it works to me (sending page happening in parallel with page being modified). I think the MSG_ZEROCOPY doc page mentioned that and it's userspace program's own choice if that happens. So even if it's not by design and not suggested, it seems not forbidden either. We can wr-protect the page (using things like userfaultfd-wp) during sending and unprotect them when it's done with a qio callback, that'll guarantee the buffer not changing during sending, however we gain nothing besides the "api cleaness" then.. Thanks, -- Peter Xu