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 D6F6820F085 for ; Thu, 23 Jan 2025 13:24:26 +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=1737638668; cv=none; b=Rgy2unb2NmGDQzeuWvKE68mWtqEkmC1BZHjcuS5WHee1K3BRhGXtNv9CnZSWAT+IcxqsnSobme99HF/lsNaGDLIV2phZftRONTFYbW8De4fuqpLu9Tfw2EMyRxD03GEvVoagAz7bCTrttsMRXLKg/IbUSQ4y5MbgBd9G53DTPTk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737638668; c=relaxed/simple; bh=IDHLqKrQSkokRQiv4vniWa+Hheh6dE9l+++Q4FF1s+U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=poTaQXt4e1Z5babtN8pI94y4mQJPKTsiFHxPnevBLSmwMNu7mzjYe3UFeQ/BmQ4FROjAvS0K9RSYxHxlbhShmHbarkQ49d74FfY68GUH3gy0ODfi6eDolkkwkFlth3Ev4YjkFP/RXvQ6W9KUEaBkbMFkRggpSLkAQYuYIWQHtnA= 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=dOUBbn+i; 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="dOUBbn+i" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737638665; 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=+2P7LG54VpcftUmxtZvCJfOrW+8I7zw3M+tnUe6zFTs=; b=dOUBbn+i+R7KOx/hxseg0vXBRyANavu3AzK4/bxExdHlj0Xm7OytaBp6Ghtzv0Ma8Ycly7 D/q3gjuI4qjn8jkh/pNMDc8npBSrF9MNdkIXeGLrhQq6bifkCzpSZHJX/tbWfmq6cHrprT iR0FK+VWxIOVCbVBpKPeXK9VN0CVu3s= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-516-G12Z6h04Mla29YMqb74MsA-1; Thu, 23 Jan 2025 08:24:24 -0500 X-MC-Unique: G12Z6h04Mla29YMqb74MsA-1 X-Mimecast-MFC-AGG-ID: G12Z6h04Mla29YMqb74MsA Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-436225d4389so9875015e9.1 for ; Thu, 23 Jan 2025 05:24:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737638663; x=1738243463; 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=+2P7LG54VpcftUmxtZvCJfOrW+8I7zw3M+tnUe6zFTs=; b=B7wpqkpE3dMTu78lDz/VclCgJ24WXCNis/mERDdfXyQJJwyGFxLVG97RCe1N2T2zjv FxoBcdmwq+PaBAn3V/F2tfXiU3VrgLdqrRNijPCeB9OhKDtsqCsfTHZmDQGN28+jDkDd 5ee7e3WfEDXYe5ES02+fVvKBJa6l7+/zJOQLDJieYS+PW8oajZab+YEVMOMtgQKIkg0l zN03qOBxh5txJgUgOW7eENgeWOMcIHntXNS4OgnKVNXZMUsmoHFZLpC+q9e8jNxyzl5L +tEa+2+hYt8wpePZNg6UjGMFAPG4iYMa8wqgjFgF+tQwAkSPd4iV78k+a0/4m+Iyrc1L Q2Hg== X-Forwarded-Encrypted: i=1; AJvYcCW+X3PaZQUklVdHQ+szWPaAsNMagajcub+hpiczIHCvXMjKbFp0mxIm4z36iNMr7b1HyT1l8tq0Fk+lzoc=@vger.kernel.org X-Gm-Message-State: AOJu0YwWDtYckDvYfoMCrtcLAYTFhxqBCmGK5E6L2ExFw7H/lcNvQYCJ 2/pdhNtPqx/tkftRfur69qpLQ8EqBkjuBcgfIwMg01GnFZOv3rqnwHiHUY4Jr34zg/hPa9q+sUp CE3Ba8pRFsA/RZV1u2+XNrIbZt7xR3YCxBI88Qh+T/L32BD1noNk0MzDCb3VLkzzU8LhJaW7lCP CvPz+gHZsn1T1zl6MHwxzCwEJ2MDJ8gPlSgJijQD9pCCo6AQ== X-Gm-Gg: ASbGnctW9xGzbYPVmbqy1TiSdaDsa8+XU4iO/Z3N0HcrcrnH2HSY6N41s6jnQ77wkkh Ndm4cktY/7lGi7fISdJ1aK0U8WEXZDx2BLFJcb1x6MAjZwxhaSr/FHZhD3FuGqxtu1DDFOh5W+B Z0dKdt+xyQ+z+FEfIXW+zfrnbUOjPOwCUblsKOMPqO2R3lkNLzBfMzh+2CtNMwongr/c8tsRF/Z f0aTT8uKYpnARDMn+AwG+u3Uhf1nXCWpTvN279dqFYq28TIyX3Y+27Iu+olw+ni X-Received: by 2002:a05:600c:4e56:b0:435:edb0:5d27 with SMTP id 5b1f17b1804b1-438b885311bmr32959995e9.9.1737638663347; Thu, 23 Jan 2025 05:24:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IEGZ8fgl/2JqYhurHCQIe5je3m7D0H/ohAnxMmCKbNiMrEty2wJfWZnNkcxEfQf3dINzx5brg== X-Received: by 2002:a05:600c:4e56:b0:435:edb0:5d27 with SMTP id 5b1f17b1804b1-438b885311bmr32959595e9.9.1737638662848; Thu, 23 Jan 2025 05:24:22 -0800 (PST) Received: from fedora (g2.ign.cz. [91.219.240.8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438b31c6fbasm61091735e9.33.2025.01.23.05.24.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jan 2025 05:24:19 -0800 (PST) From: Vitaly Kuznetsov To: Sean Christopherson Cc: Fred Griffoul , kvm@vger.kernel.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , David Woodhouse , Paul Durrant , 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> Date: Thu, 23 Jan 2025 14:24:12 +0100 Message-ID: <87frl97jer.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, Vitaly Kuznetsov wrote: >> > Signed-off-by: Fred Griffoul >> > --- >> > arch/x86/kvm/cpuid.c | 1 + >> > arch/x86/kvm/xen.c | 5 +++++ >> > arch/x86/kvm/xen.h | 5 +++++ >> > 3 files changed, 11 insertions(+) >> > >> > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c >> > index edef30359c19..432d8e9e1bab 100644 >> > --- a/arch/x86/kvm/cpuid.c >> > +++ b/arch/x86/kvm/cpuid.c >> > @@ -212,6 +212,7 @@ static int kvm_cpuid_check_equal(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2 >> > */ >> > kvm_update_cpuid_runtime(vcpu); >> > kvm_apply_cpuid_pv_features_quirk(vcpu); >> > + kvm_xen_update_cpuid_runtime(vcpu); >> >> This one is weird as we update it in runtime (kvm_guest_time_update()) >> and values may change when we e.g. migrate the guest. First, I do not >> understand how the guest is supposed to notice the change as CPUID data >> is normally considered static. > > I don't think it does. Linux-as-a-guest reads the info once during boot (see > xen_tsc_safe_clocksource()), and if and only if the TSC is constant and non-stop, > i.e. iff the values won't change. Right, the values shouldn't change on the same host. What I was thinking is what happens when we migrate the guest to another host. kvm_guest_time_update() is going to be called and we will get something different (maybe just slightly different, but still) in Xen TSC CPUIDs. The guest, however, is likely not going to notice at all. > >> Second, I do not see how the VMM is >> supposed to track it as if it tries to supply some different data for >> these Xen leaves, kvm_cpuid_check_equal() will still fail. >> >> Would it make more sense to just ignore these Xen CPUID leaves with TSC >> information when we do the comparison? > > Another alternative would be to modify the register output in kvm_cpuid(). Given > that Linux reads the info once during boot, and presumably other guests do the > same, runtime "patching" wouldn't incur meaningful overhead. And there are no > feature bits that KVM cares about, i.e. no reason KVM's view needs to be correct. True, CPUID reading time should not be performance critical. -- Vitaly