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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 93EBEC83000 for ; Wed, 29 Apr 2020 17:40:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7112120757 for ; Wed, 29 Apr 2020 17:40:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Q3jXwt47" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727084AbgD2Rk6 (ORCPT ); Wed, 29 Apr 2020 13:40:58 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:37742 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726774AbgD2Rk6 (ORCPT ); Wed, 29 Apr 2020 13:40:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588182056; 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=+ifxZyJaIcgDMF24Z/FnGdjxceJQS9w7pXlbPKDemc0=; b=Q3jXwt47s/rLcW65RCo4z8AFPM7E7U8cxtTpYwJddsT8t+gWSu+DJiNR+A1SF0KL04BYsh 7z/4DAzWtZQ4x5PGKLDg45nkL6OLw4lFUIoK6vQr5F2AQY4SZsMof1APlCSMZF6EpcAXrq 0pDFZ4/q9qq9JDpcH6rxPZ1/uKyhvwA= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-61-zyn5QC8yPsSzi-3udlZifA-1; Wed, 29 Apr 2020 13:40:55 -0400 X-MC-Unique: zyn5QC8yPsSzi-3udlZifA-1 Received: by mail-wr1-f70.google.com with SMTP id p16so2103856wro.16 for ; Wed, 29 Apr 2020 10:40:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+ifxZyJaIcgDMF24Z/FnGdjxceJQS9w7pXlbPKDemc0=; b=BBDktEyACf/ZbYO9qKe7C0TFlsiylRHaYFQiYkETCroLcuHmgZ/CAL8hRJipVrXF1+ hYZ2irj/16qAtRAdriHLinUvJVY02mDg3rh78MaPY1aSzpLYrtQZi09JBZvEimJuSSzt FRN0+2gzCIEKSR5leKiRrpgPoX+8DLjqaIVd7BZ41IqRmBDwAmJHrKAwnMKXCp1Ia+XQ bXQEnUXWFS2D4oLHSNA7iqla9cqp7Gi6CuaNFI50gv/UUdsTQZFqkFZwudAeux9U5PAX +BR31Them2rRh55G4kgybvIfGbyBd38bkpPtzrJ1sTYCBSDwGTCrLgLUEKTE2JTux60K 8roA== X-Gm-Message-State: AGi0PuaCvn8iLQdqSL5az96ElfwXkK6tocTxqqzENngfeDhFggtCkzUL ZC5tCnDYoRw/rxIpbyuj2XMwS6tsTodGg/blUWt5wJ7hYgfMXmkU7LUmzGYTDa1u8MNdTpkT7CP Tab6ZFOny0s5l X-Received: by 2002:a1c:1d92:: with SMTP id d140mr4387552wmd.67.1588182054030; Wed, 29 Apr 2020 10:40:54 -0700 (PDT) X-Google-Smtp-Source: APiQypKJurOLijS7qOB8eqd6TzSPyHSGOpNFHCTkIqRnaycYuXvYCsf9epD1BeOSFaygjfwcKqsDRA== X-Received: by 2002:a1c:1d92:: with SMTP id d140mr4387530wmd.67.1588182053727; Wed, 29 Apr 2020 10:40:53 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:2c8e:3b22:4882:7794? ([2001:b07:6468:f312:2c8e:3b22:4882:7794]) by smtp.gmail.com with ESMTPSA id n6sm33498690wrs.81.2020.04.29.10.40.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Apr 2020 10:40:53 -0700 (PDT) Subject: Re: [PATCH RFC 4/6] KVM: x86: acknowledgment mechanism for async pf page ready notifications To: Andy Lutomirski , Vitaly Kuznetsov Cc: X86 ML , kvm list , LKML , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Sean Christopherson , Wanpeng Li , Jim Mattson References: <20200429093634.1514902-1-vkuznets@redhat.com> <20200429093634.1514902-5-vkuznets@redhat.com> From: Paolo Bonzini Message-ID: <0de4a809-e965-d0ad-489f-5b011aa5bf89@redhat.com> Date: Wed, 29 Apr 2020 19:40:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 29/04/20 19:28, Andy Lutomirski wrote: > This seems functional, but I'm wondering if it could a bit simpler and > more efficient if the data structure was a normal descriptor ring with > the same number slots as whatever the maximum number of waiting pages > is. Then there would never need to be any notification from the guest > back to the host, since there would always be room for a notification. No, it would be much more complicated code for a slow path which is already order of magnitudes slower than a vmexit. It would also use much more memory. > It might be even better if a single unified data structure was used > for both notifications. That's a very bad idea since one is synchronous and one is asynchronous. Part of the proposal we agreed upon was to keep "page not ready" synchronous while making "page ready" an interrupt. The data structure for "page not ready" will be #VE. Paolo