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 A280F3451A9 for ; Wed, 8 Jul 2026 13:34: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=1783517664; cv=none; b=uHQDyD5cZI5o8r8NaYrjqR70UkmUbmNMPDxrAOt+hEBF0n6GWGuV0OVy7STpi1r1uHpwsmeEtxDtY0nuHOxcfn8aw1v/bQxmDWBKeYRjmd5tpZV0coxfrw+V0Ir48L6AfLuDe95G+ZCIg31aqE2rNkAxXyA4AAJpBmn8o/oK7qQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783517664; c=relaxed/simple; bh=agvT6dldUAVHGkvdHJr9GDkFukAf7X5C//m3Sv3mbM0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=pdZb+RW1USNKNZO3E4Djlh7TUFhFm/1VMcu3Y+T7NexeTmf/kM04LskLtQPaRxThmCsvuG0fo2mJlSv4anpOZDQJ62L6MBDKsjsE9AbfK2r6a9EUrbsidNJJ6Qjv6s2380Iy6zByqLEZnQF7UaYgmdJKCxA0P6E/BZW+ofqVI+c= 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=D5lmLxNW; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=nJBNMuhi; 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="D5lmLxNW"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="nJBNMuhi" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783517661; 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=agvT6dldUAVHGkvdHJr9GDkFukAf7X5C//m3Sv3mbM0=; b=D5lmLxNWPVYHx5/Vw4if8wRI3B+8qfDfGcrAhIvFLeSVVEHoUWQChrmtG5wgYsDq15R2Zi fqCMYzKH1fOcHPD91y4BysQnDu6vWv3nD4g3qW4LAWh/5AkPpgFg+3A/WyN69cLldmrFs8 p45BZfMqQhdV+qd9MjwgI/kMmC63s4M= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-504-gITkdlofOwaFCWlwE_BHBw-1; Wed, 08 Jul 2026 09:34:20 -0400 X-MC-Unique: gITkdlofOwaFCWlwE_BHBw-1 X-Mimecast-MFC-AGG-ID: gITkdlofOwaFCWlwE_BHBw_1783517659 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-c15b8701fe4so58167166b.2 for ; Wed, 08 Jul 2026 06:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1783517659; x=1784122459; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=agvT6dldUAVHGkvdHJr9GDkFukAf7X5C//m3Sv3mbM0=; b=nJBNMuhi8ApwLQW1V3HfDCyZT1EXfuhrdgynf67y8vGIENvnIr72HurDPqVLVLfrEA 5SRjrjZYN8fGAwGKkFZxccEIknMVehg29vq+gJLcTqyXAcNvJlpenfCCIGd/Jw0qXnBf xBbWNAPa4E5VhzPlc/E6ox6uHfEISlw2abMfCtPYooWu6GConhA27nlLf2/UQaIX9KHk ahe8HQ2zGiklhT2a4BvCkKjI9Q9wnFFuXT1bD8Sr8hlpoJfJISA/c3YGWirVnJKBuIaw 3YsLDuIOD7xqeZz3jb4jc4POIayv3a8W6YN3ciF5SrQXE9V20Q6qLl/kNlBYiHUKhItJ g/SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783517659; x=1784122459; h=mime-version:user-agent:content-transfer-encoding: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; bh=agvT6dldUAVHGkvdHJr9GDkFukAf7X5C//m3Sv3mbM0=; b=JMkzK6f4wh3r56WBdst+L61Ow7EtKsOEwiG+oR001QAAWjqK4yMJk4KdYfkFPQf0xB 4dWrOKWXNnfGZa1+sPQXKPSSBErpIzX5p9S5g89uJosWoGesEFj4/lMrBqjn8Z79eCRw CFIpCv3E62KMiBlaBqxFh3JOJzEP4tEAH+ELi8tFfU7lMryhbYUXFs0i4YcCdZ6oSkes vQwcqV6nmopK6OvUUpkSfmM8PRmWp93RcQJ/AsQ+lO5eDDXUrQWYtdLLqaUZmZRM2l+j PYMhIpumSuyK1e4ltTpC9dam2GS/C9VXT3ybGfxrL4dMwrcx0mUBp5e/o3byQIll5Rey /01g== X-Forwarded-Encrypted: i=1; AHgh+RqnkXPF1oXZcmHXchn8oX0EmRe5BeJUWKMMyXrWg3rVw24Mp9bZ8TVJJYgRdC5WxNQYAVxDkJEM5/99LhA=@vger.kernel.org X-Gm-Message-State: AOJu0YxZMFIA/BsCz0AIIxVNI5KVOLtJL5sTd3JaMg53OoCbWVDDcYVO 2C75WjzvwKBeNQkkWsNSOBcrUZM96uwbtC7wKbyyhKcoAdAyxPZIjMzVv82YvGAsELZXixXLOv1 7dIG6Vmqvh1QWFXMKBxaXOU3DFd3N1/O78fSUoD0PnoHmc5pfPPLGqi3VoeRbZbTGTQ== X-Gm-Gg: AfdE7cmGj6ey+aS+M9qgWpb/rUie9U47UIja97O1SeYRJJRut3EXph1uL3S+FhbQ/yp j2ocwieJMRcMtb21Ypj29Q/vgedpzUF3ojYbNjKRdDcdMxVBjFQcgdrJtFLt2UHQLgRrkUAaz+2 uTVzfwyAaxPtL5S48rlUB1z0AvWWyOPvSv9xU+jmeoWJ6/nUqjA21OsfDKHlqrH3tqByWBjncE3 QSP3sHyo015yQuVr/cCmpywhvilWeuIZhs6y/4GUcfvC7rUdnvq6MTD8cWD3Q+F96sG+jO3SGIJ UH2Iz8oLaz8w0q7ZBej8GmbxEg0Phzor89OcKRz1Pum2Jtzibz2CJCCEs5XusXcb5jQA1UjpjI2 WAZuGdJAuTNkWG2QPV1hlHRNYDvVyIaoayOxMekoafRP1UqdconUG55jkkOAzku8= X-Received: by 2002:a17:907:a286:b0:c12:2acc:fce2 with SMTP id a640c23a62f3a-c15ce128c8dmr130689866b.53.1783517659344; Wed, 08 Jul 2026 06:34:19 -0700 (PDT) X-Received: by 2002:a17:907:a286:b0:c12:2acc:fce2 with SMTP id a640c23a62f3a-c15ce128c8dmr130687466b.53.1783517658811; Wed, 08 Jul 2026 06:34:18 -0700 (PDT) Received: from ?IPv6:2a01:41e1:62a8:c300:7322:3fab:8db6:d28c? ([2a01:41e1:62a8:c300:7322:3fab:8db6:d28c]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c15ad84483csm333878666b.17.2026.07.08.06.34.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 06:34:18 -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: Wed, 08 Jul 2026 15:34:17 +0200 In-Reply-To: References: <20260706092021.3625908-2-twiederh@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 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 region > > 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 hitting this > > has > > to trace through KVM internals to understand what went wrong. > >=20 > > This series documents the two undocumented constraints (irqchip > > before > > vcpu, APIC base memory hole) and adds early checks so the error is > > reported at the ioctl that actually violates the constraint. > >=20 > > Patches 1-2 are documentation only.=C2=A0 Patches 3-4 add early > > validation > > that turns a confusing -EEXIST at vcpu creation into an explicit > > error > > at the point where the conflict is introduced. >=20 > I'm 100% in favor of documenting the behavior, but I'm not exactly > excited about > the enforcement.=C2=A0 It's not needed for KVM's safety, and while I > appreciate that > such a goof would be somewhat annoying to debug, I have a hard time > believing it's > a common failure.=C2=A0 I.e. I'm not convinced carrying the code is worth > the marginal > benefits it provides. FWIW, I did run into this exact issue myself and debugging it was indeed quite a ride. The EEXIST from vcpu creation led me completely astray and I was very close to just giving up. If I had, I wouldn't have written this patch, and the failure would be perceived as even less common. I don't mind dropping patches 3 and 4 (the actual "enforcement" patches) for v2, the documentation is more important in my opinion. Still, if there is interest, I'd be more than happy to rework these patches for eventual inclusion. Thanks for the review, Tim