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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B8FDC433EF for ; Thu, 20 Jan 2022 01:01:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240699AbiATBBu (ORCPT ); Wed, 19 Jan 2022 20:01:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230426AbiATBBs (ORCPT ); Wed, 19 Jan 2022 20:01:48 -0500 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37075C061574 for ; Wed, 19 Jan 2022 17:01:48 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id x16so381034pfu.13 for ; Wed, 19 Jan 2022 17:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2mfWUUkdEONMpGOlT6Rolu4VTQEpKACj2ssCBbPWHRQ=; b=MZyC4bb/dwsiefnVH0I7NG1POrw6S9lLex8pyoPh9/ZCHIzABO2zi4jvhM5U00TVHj Bdr8TVxSl4z2a/3v9UQcGnaUpRvxtt21TohxflF4DYioyS9WnWoKFac27ha+qMsLRV6a 87pbcXdwlTADh+lIgbmb8jySFU0CiUzjB97q4e9ZY2b4oRQDhj73HPMCWtc9CbkAzzcN DXB5swzvsz/4nIqu9EqHLmDd6AQQeYczTOCqz6XWDoe/MUNDGvzsF0RyYqaZaUCMHwCS lfTCJZhbRSW8O20+zf3hPl2hiwWUWfkuG7HuBYjQTRA3XzFLZo1FKVl0hrnwOlZSuTMU LjOg== 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:in-reply-to; bh=2mfWUUkdEONMpGOlT6Rolu4VTQEpKACj2ssCBbPWHRQ=; b=Try9cuWSSkxSj8OhPxB0/yZBjAhwAFK3bmO+9qVnyH/B+Lup5lA2xq+sKDI8kptT48 nJv1nU7ZhbVC14y6frb664lczHCxioqugxLfhYt5e6OAWyuhZJ3Mx0sok/X97hOblvBL Wwn4sen4ji44xQnzffyn4/Xe5XilWZBpajfHj594bWnSYv1r00JABqlk7HvdsTw6DCIV Mu12UAtgQJmDsizbokyNVhq5QCWvp6yF3pDr+JePnw7zVKlBNQRFghm24H5oHo6zPIvq vxOR7g2mEMxveeok/lXzFZ5eR3YYtrhqzZ//92dXY0X719YeBeT9qtWuqwErLaOLLtp1 bdjg== X-Gm-Message-State: AOAM533Bxj1ElLJX/OkrRMJP5nXvd8tLdaM2ejbkesGTNVtf1xCtjsAg gRDnWqtFkAG6n/40ec5DL15vhQ== X-Google-Smtp-Source: ABdhPJzntDENP9AYuT7H4j+098QA18SsfU+Q2JPLu9VgsH1SlSi1UmHfR7SWTzjGW/VtiKk4aFQQ6g== X-Received: by 2002:a63:8f09:: with SMTP id n9mr29365981pgd.38.1642640507369; Wed, 19 Jan 2022 17:01:47 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id l8sm790580pfc.187.2022.01.19.17.01.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jan 2022 17:01:46 -0800 (PST) Date: Thu, 20 Jan 2022 01:01:43 +0000 From: Sean Christopherson To: Zeng Guang Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , "kvm@vger.kernel.org" , Dave Hansen , "Luck, Tony" , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , "Huang, Kai" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Hu, Robert" , "Gao, Chao" Subject: Re: [PATCH v5 8/8] KVM: VMX: Resize PID-ponter table on demand for IPI virtualization Message-ID: References: <20211231142849.611-1-guang.zeng@intel.com> <20211231142849.611-9-guang.zeng@intel.com> <43200b86-aa40-f7a3-d571-dc5fc3ebd421@intel.com> <67262b95-d577-0620-79bf-20fc37906869@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 19, 2022, Zeng Guang wrote: > It's self-adaptive , standalone function module in kvm, no any extra > limitation introduced I disagree. Its failure mode on OOM is to degrade guest performance, _that_ is a limitation. OOM is absolutely something that should be immediately communicated to userspace in a way that userspace can take action. > and scalable even future extension on KVM_MAX_VCPU_IDS or new apic id > implementation released. > > How do you think ? :) Heh, I think I've made it quite clear that I think it's unnecesary complexity in KVM. It's not a hill I'll die on, e.g. if Paolo and others feel it's the right approach then so be it, but I really, really dislike the idea of dynamically changing the table, KVM has a long and sordid history of botching those types of flows/features.