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 A182C191F98 for ; Sat, 7 Mar 2026 00:28:51 +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=1772843332; cv=none; b=iQX0+5xhNLPF4DpWco8YPyu2JHqIl42AVnZDpcBy7BkX6Dsu5twNI2ehNWYE5+3nYCjIBP8KwwvjwegC3YbfHONNfTRLJv0VlTVaXNkJBbug6MW6xuuwvQpvuMB0vdXy2/boTP0UUbQwJ9LPp8yBl9l4FRpL0/5b41ApbRrzEAs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772843332; c=relaxed/simple; bh=QWMLlUntDiL0xIVsEqxbbJvqg3LbfJ3Wz79e3tM5FWA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=R6L/NG5B19vFB62vUhEo7Onvv8H91ufcgOeI0VBr4xOWN77KBZj5CxNZGfd3Bz7s97R5fA2prSghJFZOBGcgkQy5PDJ1rOaQ41CMIL2g865lkM24i4TEF5spvV/EHtdVvSyrVG7wlj53t2RygnZdXCmlWwaEtXOgk2KUaOKHJ+4= 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=iX3OE5qF; 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="iX3OE5qF" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-35984b91ffeso5774130a91.1 for ; Fri, 06 Mar 2026 16:28:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772843331; x=1773448131; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=tHNM+q95fw1pTGGYqDi35exVyzczshxw543JBLx5Ogc=; b=iX3OE5qFtiCoQVDsQlxF8Pmm5zbfPp/URqbfaUr46NBC8PtAo+ualv/M3Nv/0JIsGb H4/znFX1+TSerqwJGfg/SP3WLYeY0Q4dZzjxwLcKr7Yk6hcXnFXkZ29N/VSL2LuGObax DJ6DczlviSGNaZJpHGCepEtNWc1Fik5wF41n90Pgj3oK6DV/ir/l7E1r2GB9wWCL1iJB xQmlpW0YTzSJ9+PlWJcR9tGsmAGdTLhoe88sOy5WXidCSAJOErGm7XfqzhjwDlDVRli4 YhU3rDPiBuKIOMhrKMYsJpXUM/hj8LuhgTHLagYeBrZSPPMX9F4CgOacodgwiUGx7aAs ooTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772843331; x=1773448131; h=content-transfer-encoding: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=tHNM+q95fw1pTGGYqDi35exVyzczshxw543JBLx5Ogc=; b=PXRNMblqT9/oJ7++6oYxjuNLZhSFQfKHQC5CJ6SG60ohl06aZbp+rYaHxnkQ+dCwVI MLRa0tv2/HRplNyPwEbDrbFVxPSDz6Iy96eTjjMqtHtLmF3aVSF/g8dBwfeZ3C6gAz74 io5l06plZHbfgGMcezcn8LmWtANKvrdl9R029bSHTvAS7iaSs+j8MvS8KcYs4tcQotK0 l+MGzR7BZ2AHZJzVJfj3JLq88vMad6ThIpnTFXdM3R4dqggocpoCCLhVK3sK1NH/xTmw jiC8wvvIB1k01E3AQwxliri3kwkzxFubdpw5EkOGldB2eLfubmx2fSWEUW3wWhuSWzk8 20RQ== X-Forwarded-Encrypted: i=1; AJvYcCVVXPIk/g3cyMY6SU/Q/f2cDp2TGdQdjhalLOooscHjpVmHo21kS0isYeJ21TOEIYQzqJkAH/sLj0Q+pYs=@vger.kernel.org X-Gm-Message-State: AOJu0Yyl+HorapywEryMn7MKnoze45zqOkOK3PgBjrR8Fn7rk2pDOfNM iVTvBJvsgAeWE7dubbP1+0O6Y5uXUVVYbU/1/AkoO37kaC/aenwHaDQ9qwoxWbhwh51RFU7E+X0 X22DT2w== X-Received: from pjza2.prod.google.com ([2002:a17:90a:e202:b0:359:86b9:176d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3dc8:b0:359:8c5a:a564 with SMTP id 98e67ed59e1d1-359be37fc88mr3246997a91.13.1772843330852; Fri, 06 Mar 2026 16:28:50 -0800 (PST) Date: Fri, 6 Mar 2026 16:28:49 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260306210900.1933788-1-yosry@kernel.org> <20260306210900.1933788-2-yosry@kernel.org> Message-ID: Subject: Re: [PATCH v2 1/6] KVM: SVM: Use maxphyaddr in emulator RAX check for VMRUN/VMLOAD/VMSAVE From: Sean Christopherson To: Jim Mattson Cc: Yosry Ahmed , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 06, 2026, Jim Mattson wrote: > On Fri, Mar 6, 2026 at 2:37=E2=80=AFPM Yosry Ahmed wro= te: > > > > On Fri, Mar 6, 2026 at 2:27=E2=80=AFPM Jim Mattson wrote: > > > > > > On Fri, Mar 6, 2026 at 1:09=E2=80=AFPM Yosry Ahmed = wrote: > > > > > > > > Architecturally, VMRUN/VMLOAD/VMSAVE should generate a #GP if the > > > > physical address in RAX is not supported. check_svme_pa() hardcodes= this > > > > to checking that bits 63-48 are not set. This is incorrect on HW > > > > supporting 52 bits of physical address space, so use maxphyaddr ins= tead. > > > > > > > > Note that the host's maxphyaddr is used, not the guest, because the > > > > emulator path for VMLOAD/VMSAVE is generally used when virtual > > > > VMLOAD/VMSAVE is enabled AND a #NPF is generated. If a #NPF is not > > > > generated, the CPU will inject a #GP based on the host's maxphyaddr= . So > > > > this keeps the behavior consistent. > > > > > > > > If KVM wants to consistently inject a #GP based on the guest's > > > > maxphyaddr, it would need to disabled virtual VMLOAD/VMSAVE and > > > > intercept all VMLOAD/VMSAVE instructions to do the check. > > > > > > > > Also, emulating a smaller maxphyaddr for the guest than the host > > > > generally doesn't work well, so it's not worth handling this. > > > > > > If we're going to throw in the towel on allow_smaller_maxphyaddr, the > > > code should be removed. > > > > > > In any case, the check should logically be against the guest's > > > maxphyaddr, because the VMLOAD/VMSAVE instruction executes in guest > > > context. > > > > Right, but I am trying to have the #GP check for VMLOAD/VMSAVE behave > > consistently with vls=3D1, whether it's done by the hardware or the > > emulator. >=20 > Consistency should not be an issue, since VLS cannot be enabled when > the MAXPHYADDRs differ. VLS doesn't work in that scenario. >=20 > > > > > > Note that virtual VMLOAD/VMSAVE cannot be used if the guest's > > > maxphyaddr doesn't match the host's maxphyaddr. > > > > Not sure what you mean? Do you mean it wouldn't be correct to use it? > > AFAICT that doesn't prevent it from being enabled. It does, actually. KVM doesn't support allow_smaller_maxphyaddr when NPT i= s enabled, because AMD CPUs (and now some Intel CPUs, lolz) do A/D updates be= fore signalling the reserved #NPF. allow_smaller_maxphyaddr =3D !npt_enabled; And vls is disabled if NPT is disabled, for all the reasons Jim is pointing= out. if (vls) { if (!npt_enabled || !boot_cpu_has(X86_FEATURE_V_VMSAVE_VMLOAD) || !IS_ENABLED(CONFIG_X86_64)) { vls =3D false; } else { pr_info("Virtual VMLOAD VMSAVE supported\n"); } } Thus running with allow_smaller_maxphyaddr+vls is impossible. > It is incorrect to use VLS when it doesn't work.