From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6AADF264602 for ; Tue, 6 Jan 2026 01:08:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767661735; cv=none; b=MKrwjMngtZYpCcX3sgDGGMEYyCgkO8nQMC6yh+WZdSICI0QpyhpLbBOdQ9HAUsjiEMNn1YsSEEOrUB5MB4RD8m3ogk3LtU+QWFuGqcBco3UXBsUjutn1qMGzsp5RVSk5La0ShVeADFNXaVyr7qeeL953tgaWMwsbNIgG3QGGLrU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767661735; c=relaxed/simple; bh=pO0j7GuzvWJfjnqiMCHzKhY1IFHPrINkCoW5T1e+LYA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=HHJ1PmCQGLaVRZGnrAL5m1K2KqSBsNokrPQ/Q0+ZkMW3l73LzN4xoOv1vNfOTUMYKPqOZ2PuKJlYz3hIyiio7kgdc8wcXgsYh8Jn5wXMlELYT0jLz0nR5Aj6AYxHAiqg9++HBkPm3sBM1pE2amcSEQ5UKoFtKwi2vZhLCAFab3Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=IBXFTbBA; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="IBXFTbBA" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-34e5a9de94bso1146358a91.0 for ; Mon, 05 Jan 2026 17:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1767661734; x=1768266534; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=PeXJukaOG7ITY8q7wIEYbKLQQxqyX6h4rpkmy0xfeiQ=; b=IBXFTbBAJvaFtgdY6gxAXB2eAlP5uWrQ0o4f2GEglvPv0nN4edkbVVKGbrPhWHlb73 SCNtWHfmPtztXoHJfmNOu3ba5wdiCrrKViwsktESpf6J5XWZ3fk/2j4gUrgNZqg3cKLK tlFbtQR6EC+5Mz+Yq/JM8RqrqI1pbm6wy/EjrfdxvGO+AHH3bIGHTyBugJbTZUmE3C+q LNDXw1KrPXQK8WC4NBVFcGYT6X0J/+ikEdG1aAqEdVpOdTrG7fr4SK0kfl5NxHj++9e4 6Khfa2nyn6GQ2R2Q2NAEzplwnsr/8HbwuANqZqGlDILA0gvNWHiNA9YYIAlS3UzlpHnl xvAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767661734; x=1768266534; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PeXJukaOG7ITY8q7wIEYbKLQQxqyX6h4rpkmy0xfeiQ=; b=KhyXXVmE9grklkKGVYARSNM+cl9FRYvpC+/rCz2SQOM+LDb8pcVpqY+gfSi9MLlqH1 RUFCM+eUVRQ7dqiI6eoqPNCdgBDp7RsqAw+iEGHsa8pcFLqGN+bSMeWrIO36+Ax0UOTl KqX9OjKd2+xGvpv5cRp2nUsWNbUAgc/Ak7AFDlixlAf2kFPojZQN9gY4yxjKDmfbj5cD wz0E60ITMVYcMvPQaL3GXl50UjhmJqgRwYNoOMcLDikSiEQudJuVSjaVryXyIIaJ8RUd FLaoadDERXKW8EFuZIvoBQ0vbycAPBPk71hoKLXZpkszHmFeSZFiphWS30NqTo41z48n 7k1w== X-Forwarded-Encrypted: i=1; AJvYcCUs/2iIQGnTC7PJBf+1yiLAvULGOq3f923Gw0cye5G/feZFyGEujs2plYM+36kDsCEETZR+VXD6cCbjyaY=@vger.kernel.org X-Gm-Message-State: AOJu0YzAoTTF5qHLToKoY9q9Ga8JYI/QdpePvjR+2e+IDxE5qsguX89/ yEprVsx5hyd63JZ9pg2cfpyzOyZXkg5cOP5EFUw2Wls3RVYFZTToPfPG+BWljiJZ7hxBEb5R6DQ bu0sXGw== X-Google-Smtp-Source: AGHT+IG/DsAOalJyfpcjmRGKdjYsrw8KVzXpazZLXxGjc4HRgwPtIZlZ7CEqqBxQ1jpDiyfY7W01mv56pIc= X-Received: from pjji3.prod.google.com ([2002:a17:90a:6503:b0:340:c53d:2599]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:558c:b0:32e:a5ae:d00 with SMTP id 98e67ed59e1d1-34f5f271f98mr835146a91.13.1767661733717; Mon, 05 Jan 2026 17:08:53 -0800 (PST) Date: Mon, 5 Jan 2026 17:08:51 -0800 In-Reply-To: <71f42b9e-793b-4f8d-8159-a6ca7800f292@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <695c50eee68e3_4b7a100e8@dwillia2-mobl4.notmuch> <71f42b9e-793b-4f8d-8159-a6ca7800f292@intel.com> Message-ID: Subject: Re: "Paravisor" Feature Enumeration From: Sean Christopherson To: Dave Hansen Cc: dan.j.williams@intel.com, Jon Lange , Paolo Bonzini , john.starks@microsoft.com, Will Deacon , Mark Rutland , "linux-coco@lists.linux.dev" , LKML , "Kirill A. Shutemov" , Rick P Edgecombe , Andrew Cooper Content-Type: text/plain; charset="us-ascii" On Mon, Jan 05, 2026, Dave Hansen wrote: > On 1/5/26 16:01, dan.j.williams@intel.com wrote: > > Dave Hansen wrote: > ... > >> X86_FEATURE_KVM_CLOCKSOURCE in arm,pvclock > >> or > >> X86_FEATURE_KVM_STEAL_TIME in arm,kvm-steal-time > >> > >> As far as I can tell, these aliases are all done ad-hoc. This approach > >> could obviously be extended to paravisor features, but it would probably > >> be on the slow side to do it for each new feature. > > > > "Slow" as in standardization time? > > Yes. > > ... > >> Is there anything stopping us from carving out a chunk of CPUID for > >> this purpose? > > > > At what point does an ACPI property become a CPUID? In other words if > > there is an ACPI / DeviceTree enumeration of CPU/platform capabilities > > in firmware that can supsersede / extend native enumeration, does it > > matter if x86 maps that to extended CPUID space and ARM maps it however > > is convenient? > > > > I have no problem with an extended CPUID concept, just trying to > > understand more about the assumptions. > > The way it _seems_ to have worked until now is that KVM/x86 has led the > way by defining a CPUID bit for things like KVM_CLOCK of KVM_STEAL_TIME. > Then, the ARM folks came along and DeviceTree enumerations. Last, ACPI > came along with a way to package up all the DeviceTree enumerations into > a single table. > > So, maybe that's a hack on a hack on a hack and we should just start > with ACPI this time. That would certainly make this pretty straightforward. > > I'd love to hear a take from the x86/KVM folks, though. KVM x86 is blissfully unaware of ACPI. I believe the same goes for DeviceTree on ARM64, but don't quote me on that. I can't envision a world where KVM would ever enumerate or parse ACPI, let alone make ACPI a hard requirement, so any features that need KVM support need KVM specific uAPI and/or arch-specific enumeration. KVM uses CPUID for *KVM-defined* PV features on x86 because KVM already advertises support for CPUID-based features via KVM_GET_SUPPORTED_CPUID. And KVM is handed a userspace-defined virtual CPU module that includes virtual CPUID information (KVM_SET_CPUID{,2}), which KVM can then use to know whether or not a feature is enabled for a given guest. I.e. using CPUID gets KVM all the uAPI and guest ABI it needs for super cheap. PV features/devices that are provided solely by the VMM are a completely different matter. E.g. KVM similiar has no direct knowledge of VirtIO. There are plenty of optimizations in KVM that exist to make VirtIO go faster, but like ACPI, KVM is blissfully unaware of what VirtIO devices are exposed to a guest, where they reside in the platform topology, how they are enumerated to the guest, etc. Concretely, exactly what type of PV features are we talking about? To me, "Confidential Services" sounds like things that should be implemented as virtual devices in userspace, attached via whatever bus the VMM is using (e.g. vmbus vs. PCIe), and enumerated to the guest via whatever mechanism the VMM chooses (which on x86 is pretty much guaranteed to be ACPI). Trying to use CPUID for any such virtual devices will never fly in a KVM-based setup (outside of completely private/proprietary environments). KVM shouldn't ever accept a patch to define a CPUID feature for something that is conceptually a device, and Linux-as-a-guest shouldn't ever accept a patch to consume CPUID entries defined by a VMM (even if that VMM is QEMU). So unless we're talking about services that require specific, dedicated KVM support, i.e. where the KVM involvement can't be abstracted in some generic way, I don't think there's a whole lot to discuss (in a good way).