From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10CE01CDFBC for ; Thu, 23 Jan 2025 12:35:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737635724; cv=none; b=O03L2ZZimMoJP1s62o2C5yvSjhlfedY8dnHCNAwyWXWnb1uSmD3wbSW8X4fNoBgA6VwS4q64xwkJW5U6k5Cuc425khrnK/fYfl3SukQAKwjcN/uLxK+sJD02WzrmzKI7KXh0SkZ4X06Ii4Mu+gKpq/cEZ9r3loWGGrWcjqBFFNg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737635724; c=relaxed/simple; bh=xnFi+wOJypDbDOuWBma0iM8HogcsxEUv2vuCeSTtlvw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=tF76Oek0ba6GqnmXnVxWIWLPVB2jsTVg66k0HoUOBTX4bDtB4StomoahthtXqN9VdoTF5CYW8ia91vOpm2DM0uC7iix4CLzDj1GtUIR1GIJKVG250cEdn1pAm2ztLMou7XJy1B6wKLZB1/KZfXmv7pGnptDJG+tUN9OOhnJv9tE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BXS7gvt3; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BXS7gvt3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737635721; 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: in-reply-to:in-reply-to:references:references; bh=m8606wbDjuykWUSCHLg5Z4OmTqWmwe2NXbgkVdN2fJg=; b=BXS7gvt3ENO734xEbi65Jb3pZI4p2bc3SGEj8fOpCT3j6c8OwQn8iEI0o0r0aJsBgHnNCi Wpj+lqEmoLqqWIyTlX2vPIUedCxCtjAj3Dg5INjn1146aVjwj6zHHMSJEYBFKpmNO07M6R Ik7ZkZgcicBW31/ldG2Tfqy6S87yqEs= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-70-CZDdCikgNxeDlG6lUTc1YA-1; Thu, 23 Jan 2025 07:35:20 -0500 X-MC-Unique: CZDdCikgNxeDlG6lUTc1YA-1 X-Mimecast-MFC-AGG-ID: CZDdCikgNxeDlG6lUTc1YA Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4361eb83f46so7065675e9.3 for ; Thu, 23 Jan 2025 04:35:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737635719; x=1738240519; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m8606wbDjuykWUSCHLg5Z4OmTqWmwe2NXbgkVdN2fJg=; b=Im7tj/zvIVX5h9QE3vFXyFAbVrOx6VgiZ0Pgw0yi6GMYHM960tYXD9Rw8Cg4nOiZ9M pp6AGyx37f4SPPawrBs5qrLJgFECACKVj5s0TQhnVI2LKd0iXJgyWdUOhhbjHCG9XWM7 L2D2ha7Atf0I0RVsSF0UY6KxKBZMfKseyGZr3H6GpgMW/dC7izZR3ZQ8Mc7qlfrWHJPb QQPnWMNC0oEfFLYFv1fSmwgGrz7cvdT9ooXxx5kwTdGxs0XYZt3SOg1dXZp1mTJ/8L0+ 6Z7C+fdEQDilpaRUfm0oYmjOH7B+kMmAXHyioF2ihG7hrnPiJ+0Wrdly3Y/0izhb5xN8 WqQw== X-Forwarded-Encrypted: i=1; AJvYcCXdpNFfyonUCUFKSu+FZ4Yg6FqRpwoFjlDI0zx7boUZqxf0f/A7f11pOKOuTMbdxE0dJ/wL+IR0NmMn3Wo=@vger.kernel.org X-Gm-Message-State: AOJu0YxI+tuJgAsfyXTPHqBdRiwkVSWZEpzXU3sVESKqxAYEuEsTjKCk OWRjQqPgrY9IN8+GK02ZCr3p+CiT/M0jPSJC30gAF9U0pV4n8+174HOQQzlndvCBMDeUDioeJ9Y r39PRRtmAGfaSqj55P7fZkiQgONhYZeofh1HTnk+jlqz+3xs4D/QjtOkioiG2Q2Kl43xxVqGGSq bHaNcFiW+rkQMZzsu8PNHEvohv+FXsZwjYrhpXgMDI5LfR+Q== X-Gm-Gg: ASbGncsJ4LyQ80Vcdansvzb1HUCCOhiXTGI0mougpy08fP7RpSL3DxddnSpQJyYore0 9Rx3Hq87iihAPQ1800VB9vE0UWWyHAgzWJuxKDnfpY4YzAGKHaEUrHIpFnZNjiY4GpHes9YfuX6 Xl/RN2GWUyIY9dVl344kVXEJ63EZLGZXTAldIzPMHflj4zb6aib9OQ8BQj1QmnzKN86HrgY7Uvs nyAIgoTjttfIEDAAtbkvEMi75ba60/ae3Q02HSn0jl8XWf5JIiJ2unI5sP5K5Qf X-Received: by 2002:a05:600c:4e89:b0:436:30e4:459b with SMTP id 5b1f17b1804b1-438913f1649mr250850515e9.18.1737635719347; Thu, 23 Jan 2025 04:35:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IEC4nMXDk7Ulk569V8Hjp92gcI6PLi8LlyaLduqUrS8eS5+QtUPpRjnXFGrijzXxgvwLXzPHA== X-Received: by 2002:a05:600c:4e89:b0:436:30e4:459b with SMTP id 5b1f17b1804b1-438913f1649mr250850045e9.18.1737635718762; Thu, 23 Jan 2025 04:35:18 -0800 (PST) Received: from fedora (g2.ign.cz. [91.219.240.8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438b31b7655sm59718235e9.30.2025.01.23.04.35.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jan 2025 04:35:18 -0800 (PST) From: Vitaly Kuznetsov To: Sean Christopherson , David Woodhouse Cc: paul@xen.org, Fred Griffoul , kvm@vger.kernel.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: x86: Update Xen-specific CPUID leaves during mangling In-Reply-To: References: <20250122161612.20981-1-fgriffo@amazon.co.uk> <87tt9q7orq.fsf@redhat.com> <87r04u7ng7.fsf@redhat.com> <06e9f951afb46098983dc009c0efbcef3fc1b246.camel@infradead.org> Date: Thu, 23 Jan 2025 13:35:17 +0100 Message-ID: <87ldv17loa.fsf@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Sean Christopherson writes: > On Wed, Jan 22, 2025, David Woodhouse wrote: >> On Wed, 2025-01-22 at 18:44 +0100, Vitaly Kuznetsov wrote: >> > > What is the purpose of the comparison anyway? > > To avoid scenarios where KVM has configured state for a set of features X, and > doesn't correctly handle vCPU features suddenly become Y. Or more commonly, > where correctly handling such transitions (if there's even a "correct" option) > is a complete waste of time and complexity because no sane setup will ever add > and/or remove features from a running VM. > >> > > IIUC we want to ensure that a VMM does not change its mind after KVM_RUN >> > > so should we not be stashing what was set by the VMM and comparing >> > > against that *before* mangling any values? >> > >> > I guess it can be done this way but we will need to keep these 'original' >> > unmangled values for the lifetime of the vCPU with very little gain (IMO): >> > KVM_SET_CPUID{,2} either fails (if the data is different) or does (almost) >> > nothing when the data is the same. > > More importantly, userspace is allowed to set the CPUID returned by KVM_GET_CPUID2. > E.g. selftests do KVM_GET_CPUID2 specifically to read the bits that are managed > by KVM. > > Disallowing that would likely break userspace, and would create a weird ABI where > the output of KVM_GET_CPUID2 is rejected by KVM_SET_CPUID2. > >> If they're supposed to be entirely unchanged, would it suffice just to >> keep a hash of them? In case we want to support both cases: - VMM calls KVM_SET_CPUID2 at some point in vCPU's lifetime with the same data it used initially; - VMM does KVM_GET_CPUID2 and feeds this directly into KVM_SET_CPUID2 we can't use a hash as the later contains entries mangled by KVM. Currently, we kind of support both but we expect the result of the mangling done by KVM to always be the same. I guess we can change the logic the following: when KVM_SET_CPUID2 is called on a vCPU again we check that all entries which KVM did not touch match. For that, we will need to keep a list of mangled entries so we can introduce a kvm_mangle_cpuid_entry() helper to avoid the need to keep a static list. Personally, I'm not sure this is not an overkill though. -- Vitaly