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 744013E2AD2 for ; Fri, 10 Jul 2026 08:02:11 +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=1783670532; cv=none; b=I4AsS6KUPdTUKEnzVeacnr8a/1+6TuvXFTksCZ0/6yUzF7VNS971GiuIB5n2YejTDEdYZ8MoaJPwP24hl8eEhiv0zmNyKZT8PX18NVTXXFJyqCjavqpJgL/VsB+dKyY1tn8HgEf80mdjeJG+gFes3bXJx5j07mALuzhzlBS3hZ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783670532; c=relaxed/simple; bh=s/wTkh6VxtbX/sDC0CijC4ncQbmEF5imof1tuQCO9bI=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=rpHh9fQ4ELUUmb4UJ3xPIo/UBg7A396TRFgkjgB36lhosVRKLXJWCWCVIQ0jBOf84ulWcxnSa+0xkV4X3fTl2xlXOKzrsmLQ/1Y58gim0ye9ZJkUv8F6DfU+zTODTcAfjVbgsek8nFvedGmiMMXFB9ZTFNq4ew5pBuVbDURtOio= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine 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=H6y/9RHU; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=PTWsO+UZ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine 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="H6y/9RHU"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="PTWsO+UZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783670530; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s/wTkh6VxtbX/sDC0CijC4ncQbmEF5imof1tuQCO9bI=; b=H6y/9RHUayGNFj8XJpyIK1j/+37BGyvlLfsS9r57ZfzTFIyqP0UVSvh8vVBdzcFe4UGwID 5WO/6VsiCxVijrngsWEaWR/A71I4/4OW4Dl5dINw0cHUyZWv3avgbEP12cZ+7Nrfkzv0PR WkRwlFlcB5hA4X/8zbLLbKrYpHMJu+E= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-394-dOA_Zni4OHyb27dU1gFfbQ-1; Fri, 10 Jul 2026 04:02:09 -0400 X-MC-Unique: dOA_Zni4OHyb27dU1gFfbQ-1 X-Mimecast-MFC-AGG-ID: dOA_Zni4OHyb27dU1gFfbQ_1783670528 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-c15d113dd65so56053266b.0 for ; Fri, 10 Jul 2026 01:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1783670528; x=1784275328; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=s/wTkh6VxtbX/sDC0CijC4ncQbmEF5imof1tuQCO9bI=; b=PTWsO+UZtBo/iKKtOh5LqDMRSB5xkCvtjgDbatwnzSTwYAPtyb9FSP2r/GXNaNHd3x Ubo7eyDqlp4DKZfdr130npFmmLHXZT3lz1vHi+BaB9ffPfMlO7YjfRtIrhq8cI9sWyHE IN74R6K5t2fEgOkB4xfheYVOCTFXSHrkeLQIlUnselYxd7SzmpFkhEidH1D8JAKOck4/ pP55ZR+dzL4P82pQiG9fmBL2oyO2IiqV/FmjAetwJoLWxk90EP/aODpgQN1nWuHwXJdH t4Q4788ZUH1QNWutFPEMbZ+9Jt+p4IYJDlbpyALgmdRZ8VwIVoCxPXhWOWPfkgbZ3RaN VnGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783670528; x=1784275328; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=s/wTkh6VxtbX/sDC0CijC4ncQbmEF5imof1tuQCO9bI=; b=kOd+UsKQkcuiW6qf0Gq/TFQU8FpUM9UgAXcYAr+IXYNXej+Hsj8Hp3mdGUjF2UF22T NMbK9G+bLMjr8Ju7Xg8BVw9Wg5dh/Wt3uBnRBdFA7F4RmvkH8L08gTWuUyxrR5Q6hjs1 3w+nayDhDYJltQgz+p4CM3gKxuuuIN08EFWn0UCCXIcglgZu+/TfhernUlf6/CB+Q9ZZ J/SUTcLgOlEanWShB+mQTKwC6UYKNPxDelfXPy38f5veizOORbD7OFM8oov954P9Rx0l 3jeglkt0I48I7MCoBTxIAV/Cz+MX6I2OPbg3zoxhJ4v1aNRb9foMa9s6GZ35m293Xrkq dyuw== X-Forwarded-Encrypted: i=1; AHgh+RpT0DyBE0VOXPLzlz8qkUcFKVFipCss3ipMvk7vJ4h8Q3B7syaKJo5T6VE3CPjdCZNA6GrUurgd5Yqm9pc=@vger.kernel.org X-Gm-Message-State: AOJu0YzSgifk9Ca5TsUMhVLSI9EuY4DEREkXQfVUtQxopEORfumzTNFg XyEMZWRTmJTN6tv1CuGhKLzC0z8H1G10tR+R609KrTEZQVsLCNjic9znHrEzPPvgWpK+cuNlvbZ 335LJL0LwAcBH4bZVP0I0fhBlorUHz8Ogw+TejAvR45HRfihfpxHimFIrFhrozQstSw== X-Gm-Gg: AfdE7clnhdmJItsqOxCF+hXI13B3KqPIK0hEBtgE5xIhLmxP0cbNJ1kEtZFPD+goBbl 0zs8IH5FGvLm0WgUlOE6giZM85BEoVfGlz4JDhcPyOqs1wd7bnkXpr8u8/u1s0WRGT6car501fy 03Yd7x2ix0yd7RUU6/cZX1WM9cOO7tufnMMVyxKWykI48GBy8aoSHKnhYNF+stUd6vYS6IR70+G pFW03wqAETMM2wO7sRL6hFHI8oMYmroj4+8tpj3J0URhKAcEe/A/dyoe0XJwjqRh2xgJcfGfr6l 91FPR0HMQycPb3QCM9AySSxKk32s/Gpu9EBzaNBxjKcimqiFH6hsi8AFidatZ4utW4C8QfUvx3N iAhivKyzAk7DKrsLkSRgOSkhuaSmYe2mC43d2n62LoavqhUZ3V4fge8GA5PPg X-Received: by 2002:a17:907:d50c:b0:c15:d08a:2cb1 with SMTP id a640c23a62f3a-c15fe271f91mr103709866b.0.1783670527683; Fri, 10 Jul 2026 01:02:07 -0700 (PDT) X-Received: by 2002:a17:907:d50c:b0:c15:d08a:2cb1 with SMTP id a640c23a62f3a-c15fe271f91mr103708166b.0.1783670527209; Fri, 10 Jul 2026 01:02:07 -0700 (PDT) Received: from ?IPv6:2a01:41e1:62d2:1700:b0c7:4985:769b:d2d? ([2a01:41e1:62d2:1700:b0c7:4985:769b:d2d]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-69a19ce4ad4sm10624182a12.12.2026.07.10.01.02.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2026 01:02:06 -0700 (PDT) Message-ID: Subject: Re: [PATCH 0/4] KVM: x86: Document and enforce APIC base memory hole From: Tim Wiederhake To: Sean Christopherson Cc: Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , Jonathan Corbet , kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Shuah Khan , Thomas Gleixner , x86@kernel.org Date: Fri, 10 Jul 2026 10:02:06 +0200 In-Reply-To: References: <20260706092021.3625908-2-twiederh@redhat.com> <8b35057f72cd281637cf9d4bcbe1d0d753a3710e.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Thu, 2026-07-09 at 10:38 -0700, Sean Christopherson wrote: > On Wed, Jul 08, 2026, Tim Wiederhake wrote: > > On Wed, 2026-07-08 at 06:41 -0700, Sean Christopherson wrote: > > > On Wed, Jul 08, 2026, Tim Wiederhake wrote: > > > > On Mon, 2026-07-06 at 15:26 -0700, Sean Christopherson wrote: > > > > > On Mon, Jul 06, 2026, Tim Wiederhake wrote: > > > > > > When an in-kernel irqchip is enabled on x86, KVM installs a > > > > > > private > > > > > > memory slot at the default APIC base address (0xfee00000) > > > > > > during vcpu > > > > > > creation.=C2=A0 If user space has already mapped a memory regio= n > > > > > > covering > > > > > > that address, vcpu creation fails with -EEXIST.=C2=A0 The same > > > > > > happens in > > > > > > reverse: mapping memory over the APIC base after vcpu > > > > > > creation also > > > > > > fails with -EEXIST. > > > > > >=20 > > > > > > None of this is documented, and the error is reported far > > > > > > from where > > > > > > the actual conflict is introduced.=C2=A0 A VMM developer hittin= g > > > > > > this has > > > > > > to trace through KVM internals to understand what went > > > > > > wrong. > > > > > I'm 100% in favor of documenting the behavior, but I'm not > > > > > exactly > > > > > excited about the enforcement. >=20 > ... >=20 > > > > FWIW, I did run into this exact issue myself and debugging it > > > > was > > >=20 > > > What were you doing (or trying to do?) when you ran afoul of > > > this?=C2=A0 I ask > > > because maybe there's a way to help developers without impacting > > > KVM's > > > uABI. > >=20 > > Experimenting, mostly with pmode code.=20 >=20 > "pmode" being Protected Mode?=C2=A0 Or something else? >=20 Yes, Protected Mode. > > For simplicity, I use a single memory slot at 0x0. Due to an off- > > by-one > > error, I gave the VM only 2 GB instead of 4 GB as intended. When I > > fixed > > that, suddenly vcpu creation failed. >=20 > Heh, fun.=C2=A0 I don't think there's a good answer here.=C2=A0 Or rather= , I > don't think > there's an answer that you'll find satisfying.=C2=A0 "Unintentionally" > creating a > memslot that overlaps the PCI hole and the RESET vector is always > going to end > in tears unless VMM and the guest are doing very special things.=C2=A0 > I.e. not > covering up the local APIC base is so foundational that trying to > guard against > it in KVM isn't worthwhile, because such a goof is just the tip of > the iceberg. I noticed :). And I learned a lot from the experience, which made it worthwhile. But I'd love to make the experience less painful for the next person, hence v2 that puts up some warning signs in the docs: =20 https://lore.kernel.org/kvm/20260708133856.302151-1-twiederh@redhat.com/