From nobody Sun Nov 24 17:22:02 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1727713152; cv=none; d=zohomail.com; s=zohoarc; b=BHcVhJdNyeGUWckaCCe0aFRO4yhMUwoqHLaMrLC966hXlAZvX60xcMpEYsjCw5zyQiZAVm23cE7vi8YLoW+e7TQrB1eHxADnB5CdtWuidF8qReEorxTSZnDFXSZ2o54l/9tCTJa/K1rpd7LCtB543Jifhmcaw/NZvorvRYr0d2w= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1727713152; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=6gNq1CiPxbw6BvasIllJEVVgG1TpzbWw2PuiFCsE680=; b=O76FAV8/Rlv2qhF4YZMkguJoJusZv3sKCMElDW5Eu8rZehfuQpbk/nAv3pjsgDiLJZi78Y73+bU0ZM5WRpEXVrh3qX5R9GSIItwHqizYhhbEOjyEuSyjzrIr1SXCbuXMKWxdMSFPR2mPCm6gxpxGQVwDGAkAdZzZBZ0yDoMM8ts= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1727713152642500.8561725776939; Mon, 30 Sep 2024 09:19:12 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.807551.1219089 (Exim 4.92) (envelope-from ) id 1svJ6i-0001DH-Nq; Mon, 30 Sep 2024 16:18:44 +0000 Received: by outflank-mailman (output) from mailman id 807551.1219089; Mon, 30 Sep 2024 16:18:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1svJ6i-0001CR-HE; Mon, 30 Sep 2024 16:18:44 +0000 Received: by outflank-mailman (input) for mailman id 807551; Mon, 30 Sep 2024 16:18:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1svJ6h-00019g-6Z for xen-devel@lists.xenproject.org; Mon, 30 Sep 2024 16:18:43 +0000 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [2a00:1450:4864:20::633]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a848fd9d-7f47-11ef-a0ba-8be0dac302b0; Mon, 30 Sep 2024 18:18:41 +0200 (CEST) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a8d43657255so712779966b.0 for ; Mon, 30 Sep 2024 09:18:41 -0700 (PDT) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93c2776d83sm550760366b.43.2024.09.30.09.18.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Sep 2024 09:18:39 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a848fd9d-7f47-11ef-a0ba-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1727713120; x=1728317920; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6gNq1CiPxbw6BvasIllJEVVgG1TpzbWw2PuiFCsE680=; b=MEIXRQD6kSFSjbRsWGCgJG0wfFdxWv6x1BdOjkM0wquKNt1AN6WSr7C58O1/JqrKXq X/TP7IDwPqNWvCuxJY7kiK3p5+QpCg7oU1LTpWfxixHqcORbxRFNVurafLKoXyyY/XHS K8pWofkce2D3zlo/ida4jhnJpbvdDw8tme/10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727713120; x=1728317920; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6gNq1CiPxbw6BvasIllJEVVgG1TpzbWw2PuiFCsE680=; b=PEdiSfKl/axwm8uDHQucDpxyCrsVsXsUxFZf3ueHONr+a3aRM9GO8dbLBuoBYNWtfd rTEbElb0t7L6gYkupVztc0+TYjMJgRW0o+i0Z5YeTdH22Tot0B5cW6Rd1IxgdEy0/tLA gRonvyjFLxprW3YOk8LyjJ/Wwdxqip0G/Stjne8F6FlNbwzO4von+TG2UVeYp15AZQ0u OyzBc43dXpzF61Oi5x2k4cCaoxb4So+2VP+1ztxCa3rKBI2Kn48MU7Z3BzWM6RHPAVgk ozfsQ7f+9tFvsNEaQo/MCmqNKxUjn/3f0m99shevLmkSq+QKzIy9ofOgntzerbUIpJA1 Wa9g== X-Gm-Message-State: AOJu0YyDEPikHzA0iK6gJshgCXvxkGheef5yAhT5jnGb2jG5rBlcCVir f64tfCzQYvoLgEoRByTk59SJk2gy7dryRQBLWOdlO/lCDyUONYMxL9HrxXV3PDdQv4RfZypIfrl U4E4= X-Google-Smtp-Source: AGHT+IGFsONaHL8RhvJNZdPGs/IjRVi7nzxDHvjGgE3s3eyYW3TehH+dXB2OaMJmOfI3fxkF5N613Q== X-Received: by 2002:a17:906:730c:b0:a87:31c:c6c4 with SMTP id a640c23a62f3a-a93c490a094mr1658600466b.24.1727713120385; Mon, 30 Sep 2024 09:18:40 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 1/2] x86/pv: Rework guest_io_okay() to return X86EMUL_* Date: Mon, 30 Sep 2024 17:18:36 +0100 Message-Id: <20240930161837.1248144-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20240930161837.1248144-1-andrew.cooper3@citrix.com> References: <20240930161837.1248144-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1727713153595116600 In order to fix a bug with guest_io_okay() (subsequent patch), rework guest_io_okay() to take in an emulation context, and return X86EMUL_* rather than a boolean. For the failing case, take the opporunity to inject #GP explicitly, rather than returning X86EMUL_UNHANDLEABLE. There is a logical difference between "we know what this is, and it's #GP", vs "we don't know what this is". There is no change in practice as emulation is the final step on general #GP resolution, but returning X86EMUL_UNHANDLEABLE would be a latent bug if a subsequent action were to appear. No practical change. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 --- xen/arch/x86/pv/emul-priv-op.c | 36 ++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 13 deletions(-) diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index b90f745c75ea..978bd6c0775f 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -156,14 +156,16 @@ static bool iopl_ok(const struct vcpu *v, const struc= t cpu_user_regs *regs) } =20 /* Has the guest requested sufficient permission for this I/O access? */ -static bool guest_io_okay(unsigned int port, unsigned int bytes, - struct vcpu *v, struct cpu_user_regs *regs) +static int guest_io_okay(unsigned int port, unsigned int bytes, + struct x86_emulate_ctxt *ctxt) { + struct cpu_user_regs *regs =3D ctxt->regs; + struct vcpu *v =3D current; /* If in user mode, switch to kernel mode just to read I/O bitmap. */ const bool user_mode =3D !(v->arch.flags & TF_kernel_mode); =20 if ( iopl_ok(v, regs) ) - return true; + return X86EMUL_OKAY; =20 if ( (port + bytes) <=3D v->arch.pv.iobmp_limit ) { @@ -190,10 +192,12 @@ static bool guest_io_okay(unsigned int port, unsigned= int bytes, toggle_guest_pt(v); =20 if ( (x.mask & (((1 << bytes) - 1) << (port & 7))) =3D=3D 0 ) - return true; + return X86EMUL_OKAY; } =20 - return false; + x86_emul_hw_exception(X86_EXC_GP, 0, ctxt); + + return X86EMUL_EXCEPTION; } =20 /* Has the administrator granted sufficient permission for this I/O access= ? */ @@ -353,12 +357,14 @@ static int cf_check read_io( struct priv_op_ctxt *poc =3D container_of(ctxt, struct priv_op_ctxt, c= txt); struct vcpu *curr =3D current; struct domain *currd =3D current->domain; + int rc; =20 /* INS must not come here. */ ASSERT((ctxt->opcode & ~9) =3D=3D 0xe4); =20 - if ( !guest_io_okay(port, bytes, curr, ctxt->regs) ) - return X86EMUL_UNHANDLEABLE; + rc =3D guest_io_okay(port, bytes, ctxt); + if ( rc !=3D X86EMUL_OKAY ) + return rc; =20 poc->bpmatch =3D check_guest_io_breakpoint(curr, port, bytes); =20 @@ -458,12 +464,14 @@ static int cf_check write_io( struct priv_op_ctxt *poc =3D container_of(ctxt, struct priv_op_ctxt, c= txt); struct vcpu *curr =3D current; struct domain *currd =3D current->domain; + int rc; =20 /* OUTS must not come here. */ ASSERT((ctxt->opcode & ~9) =3D=3D 0xe6); =20 - if ( !guest_io_okay(port, bytes, curr, ctxt->regs) ) - return X86EMUL_UNHANDLEABLE; + rc =3D guest_io_okay(port, bytes, ctxt); + if ( rc !=3D X86EMUL_OKAY ) + return rc; =20 poc->bpmatch =3D check_guest_io_breakpoint(curr, port, bytes); =20 @@ -612,8 +620,9 @@ static int cf_check rep_ins( =20 *reps =3D 0; =20 - if ( !guest_io_okay(port, bytes_per_rep, curr, ctxt->regs) ) - return X86EMUL_UNHANDLEABLE; + rc =3D guest_io_okay(port, bytes_per_rep, ctxt); + if ( rc !=3D X86EMUL_OKAY ) + return rc; =20 rc =3D read_segment(x86_seg_es, &sreg, ctxt); if ( rc !=3D X86EMUL_OKAY ) @@ -678,8 +687,9 @@ static int cf_check rep_outs( =20 *reps =3D 0; =20 - if ( !guest_io_okay(port, bytes_per_rep, curr, ctxt->regs) ) - return X86EMUL_UNHANDLEABLE; + rc =3D guest_io_okay(port, bytes_per_rep, ctxt); + if ( rc !=3D X86EMUL_OKAY ) + return rc; =20 rc =3D read_segment(seg, &sreg, ctxt); if ( rc !=3D X86EMUL_OKAY ) --=20 2.39.5 From nobody Sun Nov 24 17:22:02 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1727713155; cv=none; d=zohomail.com; s=zohoarc; b=Fe1Ut6fPOOmspiwewo4MBBOdQGF/wA2pjWMqsI+sTI1wNJfg6beTzP29MbPemurE2QKSfPif3OYmP3kn6OYFK1iVxzu4Jyw2lbydo1tBeuh1uJoyULhZsHPdJfX79SXF1MwTTChQRxxvkDnjkjjeJflU+GkiVkkFFFBOg/lgEuA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1727713155; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=4XvczQYxmpdcGE+M38uBRSt699wzNn8bkg2MtX8Hvg4=; b=EaPBDteu7HuJDm7iJQoQbYlreedoKOCu5kszdihfHADaiZy9Omd2+FK7wSFCJTv2BX9hKSk8p3zw1tLTNLuHgm2tY5ql//42pGgt3R8XrT0TrJaY4Qy823fIg79a7JxHBqMOXeFUPu0E/ETJ0uwnKik8B3u59h3nHYt5GCG5f4w= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1727713155091277.99535466843963; Mon, 30 Sep 2024 09:19:15 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.807552.1219104 (Exim 4.92) (envelope-from ) id 1svJ6j-0001cA-T0; Mon, 30 Sep 2024 16:18:45 +0000 Received: by outflank-mailman (output) from mailman id 807552.1219104; Mon, 30 Sep 2024 16:18:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1svJ6j-0001c3-OY; Mon, 30 Sep 2024 16:18:45 +0000 Received: by outflank-mailman (input) for mailman id 807552; Mon, 30 Sep 2024 16:18:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1svJ6i-00019g-6r for xen-devel@lists.xenproject.org; Mon, 30 Sep 2024 16:18:44 +0000 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [2a00:1450:4864:20::235]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a9412057-7f47-11ef-a0ba-8be0dac302b0; Mon, 30 Sep 2024 18:18:43 +0200 (CEST) Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2fac6b3c220so16923361fa.2 for ; Mon, 30 Sep 2024 09:18:43 -0700 (PDT) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93c2776d83sm550760366b.43.2024.09.30.09.18.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Sep 2024 09:18:40 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a9412057-7f47-11ef-a0ba-8be0dac302b0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1727713122; x=1728317922; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=4XvczQYxmpdcGE+M38uBRSt699wzNn8bkg2MtX8Hvg4=; b=aninZlTvy47wiHsA4B81wJyLCoO+Z0xxSGvWy9dv+hcvuqdKKYS30JFocrKe8EXGqW YQp18bwkeooJygefxvtv4+rtIIHZAXonPjlPQhw211ivfULc2W5Kt8/bDiOZX1uIuqK6 GlZkcZQuABHG+MPUOvy7q3CaoliCF/gI2TKac= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727713122; x=1728317922; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4XvczQYxmpdcGE+M38uBRSt699wzNn8bkg2MtX8Hvg4=; b=JnsKanjOYf8jLq3pqWhpiqL0h13ANJ1jRArWMqBirq6uHvlHQrT7/nuh2zAOiPuzY0 zkbhj2LId69WDM/OABY5zawJ1G/yrpGJiv2MFKfTJJ/8HBGuAc7B8E/eRUkTI0+wM0Yj dXkAIDNPDgsoTkLP02KvCZxwz2A2xjuNjPgM4tuhHoCfs1CAxHcXlr+RN7JOnl710S/U R9K+Fj8YGOQkaHmaW0qim2vkVjvrhWL8U1zyii6i4tOFergUy+HQ4dCGjbJinsVp3Wja 0BCGhBQG9yNDVsxl3pXi9nzkS7qYxS3Mdr7LrOUOq0s9/o9qIjdG8xhoVQlLy+RmvkD1 985w== X-Gm-Message-State: AOJu0Yze74nRig3K6CtcYLXxNu+0bCt2VcFF3fcJsiD95fa92xYx9Ye5 TH0vHjxVuG8b4eSt+Rh/W1wWTb92Qd0e7M/QeTpRb87YcU4O4FHNjUdQotTkSr6Fx7y4/vXD8Vu zA4Y= X-Google-Smtp-Source: AGHT+IHnDeu5tUI/rEWPnJa+PJrqcJutctAaKn1KNG+qCw1NteztUZnhVaOlAbbH0gZaRyVjXWhflQ== X-Received: by 2002:a2e:a990:0:b0:2fa:cfba:fb7f with SMTP id 38308e7fff4ca-2facfbafe44mr28805361fa.40.1727713122128; Mon, 30 Sep 2024 09:18:42 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 2/2] x86/pv: Handle #PF correctly when reading the IO permission bitmap Date: Mon, 30 Sep 2024 17:18:37 +0100 Message-Id: <20240930161837.1248144-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20240930161837.1248144-1-andrew.cooper3@citrix.com> References: <20240930161837.1248144-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1727713155537116600 The switch statement in guest_io_okay() is a very expensive way of pre-initialising x with ~0, and performing a partial read into it. However, the logic isn't correct either. In a real TSS, the CPU always reads two bytes (like here), and any TSS limit violation turns silently into no-access. But, in-limit accesses trigger #PF as usual. AMD document this property explicitly, and while Intel don't (so far as I can tell), they do behave consistently with AMD. Switch from __copy_from_guest_offset() to __copy_from_guest_pv(), like everything else in this file. This removes code generation setting up copy_from_user_hvm() (in the likely path even), and safety LFENCEs from evaluate_nospec(). Change the logic to raise #PF if __copy_from_guest_pv() fails, rather than disallowing the IO port access. This brings the behaviour better in line w= ith normal x86. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 RFC: Should we make the boundary check be (port + bytes + 8)? That would be more correct, but liable to break unsuspecting VMs. Maybe we should just comment our way out of it. This needs to be combined with Jan's "x86/PV: simplify (and thus correct) guest accessor functions" to function completely correctly. From XTF testi= ng: This series on its own: --- Xen Test Framework --- Environment: PV 64bit (Long mode 4 levels) Test pv-emul-cr2 Error: %cr2 expected 0x3000, got 0x2fff Test result: ERROR This series plus Jan's fix: --- Xen Test Framework --- Environment: PV 64bit (Long mode 4 levels) Test pv-emul-cr2 Test result: SUCCESS Interestingly, the test also does an `INW` without an output parameter straddling that page boundary, and it does reliably get 0x3000 even without the accessor fix. --- xen/arch/x86/pv/emul-priv-op.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index 978bd6c0775f..b5d184038fa3 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -169,29 +169,26 @@ static int guest_io_okay(unsigned int port, unsigned = int bytes, =20 if ( (port + bytes) <=3D v->arch.pv.iobmp_limit ) { - union { uint8_t bytes[2]; uint16_t mask; } x; + const void *__user addr =3D v->arch.pv.iobmp.p + (port >> 3); + uint16_t mask; + int rc; =20 - /* - * Grab permission bytes from guest space. Inaccessible bytes are - * read as 0xff (no access allowed). - */ + /* Grab permission bytes from guest space. */ if ( user_mode ) toggle_guest_pt(v); =20 - switch ( __copy_from_guest_offset(x.bytes, v->arch.pv.iobmp, - port>>3, 2) ) - { - default: x.bytes[0] =3D ~0; - /* fallthrough */ - case 1: x.bytes[1] =3D ~0; - /* fallthrough */ - case 0: break; - } + rc =3D __copy_from_guest_pv(&mask, addr, 2); =20 if ( user_mode ) toggle_guest_pt(v); =20 - if ( (x.mask & (((1 << bytes) - 1) << (port & 7))) =3D=3D 0 ) + if ( rc ) + { + x86_emul_pagefault(0, (unsigned long)addr + bytes - rc, ctxt); + return X86EMUL_EXCEPTION; + } + + if ( (mask & (((1 << bytes) - 1) << (port & 7))) =3D=3D 0 ) return X86EMUL_OKAY; } =20 --=20 2.39.5 From nobody Sun Nov 24 17:22:02 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1727785508; cv=none; d=zohomail.com; s=zohoarc; b=UoXrZmyqsuOYoajuEa1JDhb+EpRDxrawZfOYaFHQeSEPCZDnV0qbU3pWzY95TVDLPZbSi6Vpd/9g3BNakA7Fw+ZuXhiyL4NQHiT4nt2W/eUvWInUPLXpsJ7Xs8+Fpod66SCRKMA7BBwChEzL2QFkXyj21c35X/3LFpbeGJy4vHc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1727785508; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=qHkm+gTmN+S5hP1Q9mE4edudlBV+IDvZ/Wxl24devZo=; b=ZsznsgihjNqk/3ABOwibX3d0W/GXO3Rv7PYq17yLNaehjz92Vk/7/UND+4OAYC0wrAk77JDjnE5eQxlTCg2Hr1rWDfRxGJ6FQ2ToHRjtp6qYMMSDarYKTfBYMW6Y1IqIA68x47Yq35CKNug//tCPg7RjdoxSMlkQ28YS3YDAdwU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1727785508085643.8319476867175; Tue, 1 Oct 2024 05:25:08 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.808059.1219846 (Exim 4.92) (envelope-from ) id 1svbvp-0000kv-AA; Tue, 01 Oct 2024 12:24:45 +0000 Received: by outflank-mailman (output) from mailman id 808059.1219846; Tue, 01 Oct 2024 12:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1svbvp-0000ko-7R; Tue, 01 Oct 2024 12:24:45 +0000 Received: by outflank-mailman (input) for mailman id 808059; Tue, 01 Oct 2024 12:24:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1svbvo-0000ki-ER for xen-devel@lists.xenproject.org; Tue, 01 Oct 2024 12:24:44 +0000 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [2a00:1450:4864:20::642]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 22a4f42b-7ff0-11ef-99a2-01e77a169b0f; Tue, 01 Oct 2024 14:24:42 +0200 (CEST) Received: by mail-ej1-x642.google.com with SMTP id a640c23a62f3a-a93c1cc74fdso830994566b.3 for ; Tue, 01 Oct 2024 05:24:42 -0700 (PDT) Received: from andrewcoop.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93c27c70fesm700089266b.57.2024.10.01.05.24.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Oct 2024 05:24:40 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 22a4f42b-7ff0-11ef-99a2-01e77a169b0f DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1727785481; x=1728390281; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qHkm+gTmN+S5hP1Q9mE4edudlBV+IDvZ/Wxl24devZo=; b=ugbyEaEGFXDTnyR8o+7bO1koejkUPi1y6jVcxTF7fHmUgfYIC3MsSJR3u2qjqlESnf R8IFNMxla3Byb70AGDjfUO+pVQZJ7mxWLyDW511zcL5urh4TpJ/qzay6Wf6URpwgjngs 8MjZlGeQhBF/2dQ4EARrkLdwrXroTRWkoauLs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727785481; x=1728390281; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qHkm+gTmN+S5hP1Q9mE4edudlBV+IDvZ/Wxl24devZo=; b=FmRK7QVnSswq0mY51VAYV51GrqzAHgxE2PzMT+kzDUYqFbQNE66OwDxMt3WmvpAj7m wb0ZWom7gUKO1WWEVi1CS0L93PduuoxpdYZH04+hkHDWOyUddvgfLYvrEUozphcQ9n9y KIj5MddKcnjyPt5s2UFZpF4pzM7za4yTmlHDWjxHcZDBrgdF1izkmzR+UiBnRc+CHIkc bt8ju6butepMMEvX7MXtTdJB41b/JA4yqQ6XZZW0bK087utx/ybs/wyo7NO8GnqCf1uU T/cCp/HEAfSNfae5Pr1v04rUHU1/6YWohexeCXSkFCNjIx/6v5usmwLpUQDb9FDziF5o WeLg== X-Gm-Message-State: AOJu0Yw2CeZLPH57fLpjz4DwNP7BscyLBbKsd0vA/vUIdd5+gIW2OyDg OM1oE9+vl+wI5++G1e973xsKoOG/8jK2LvFZlrC974RAud34VZ0jNe5Px4M2OHo2QJQYq+BFvmk Tf3QFnA== X-Google-Smtp-Source: AGHT+IFXb+nZshPjMeWW4itYiYhIxAwo6/5FdstYB+n+kXcxh8r2whiBxQZfHzyKz+GNVCW6/W4dzw== X-Received: by 2002:a17:907:7e8c:b0:a8d:2ab2:c9a0 with SMTP id a640c23a62f3a-a93c4aae066mr1531904366b.53.1727785481370; Tue, 01 Oct 2024 05:24:41 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH 3/2] x86/pv: Rename pv.iobmp_limit to iobmp_nr and clarify behaviour Date: Tue, 1 Oct 2024 13:24:38 +0100 Message-Id: <20241001122438.1454218-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20240930161837.1248144-1-andrew.cooper3@citrix.com> References: <20240930161837.1248144-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1727785510175116600 Ever since it's introduction in commit 013351bd7ab3 ("Define new event-chan= nel and physdev hypercalls"), the public interface was named nr_ports while the internal field was called iobmp_limit. Rename the intenral field to iobmp_nr to match the public interface, and clarify that, when nonzero, Xen will read 2 bytes. There isn't a perfect parallel with a real TSS, but iobmp_nr being 0 is the paravirt "no IOPB" case, and it is important that no read occurs in this ca= se. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 --- xen/arch/x86/include/asm/domain.h | 2 +- xen/arch/x86/physdev.c | 2 +- xen/arch/x86/pv/emul-priv-op.c | 7 ++++++- xen/include/public/physdev.h | 3 +++ 4 files changed, 11 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/include/asm/domain.h b/xen/arch/x86/include/asm/d= omain.h index 811251852f79..bdcdb8de09f1 100644 --- a/xen/arch/x86/include/asm/domain.h +++ b/xen/arch/x86/include/asm/domain.h @@ -573,7 +573,7 @@ struct pv_vcpu =20 /* I/O-port access bitmap. */ XEN_GUEST_HANDLE(uint8) iobmp; /* Guest kernel vaddr of the bitmap. */ - unsigned int iobmp_limit; /* Number of ports represented in the bitmap= . */ + unsigned int iobmp_nr; /* Number of ports represented in the bitmap= . */ #define IOPL(val) MASK_INSR(val, X86_EFLAGS_IOPL) unsigned int iopl; /* Current IOPL for this VCPU, shifted left = by * 12 to match the eflags register. */ diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c index d6dd622952a9..69fd42667c69 100644 --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -436,7 +436,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(voi= d) arg) #else guest_from_compat_handle(curr->arch.pv.iobmp, set_iobitmap.bitmap); #endif - curr->arch.pv.iobmp_limit =3D set_iobitmap.nr_ports; + curr->arch.pv.iobmp_nr =3D set_iobitmap.nr_ports; break; } =20 diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index e35285d4ab69..cefa38d56138 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -167,7 +167,12 @@ static int guest_io_okay(unsigned int port, unsigned i= nt bytes, if ( iopl_ok(v, regs) ) return X86EMUL_OKAY; =20 - if ( (port + bytes) <=3D v->arch.pv.iobmp_limit ) + /* + * When @iobmp_nr is non-zero, Xen, like real CPUs and the TSS IOPB, + * always reads 2 bytes from @iobmp, which might be one byte beyond + * @nr_ports. + */ + if ( (port + bytes) <=3D v->arch.pv.iobmp_nr ) { const void *__user addr =3D v->arch.pv.iobmp.p + (port >> 3); uint16_t mask; diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h index 45e1c18541c8..3149049a9a57 100644 --- a/xen/include/public/physdev.h +++ b/xen/include/public/physdev.h @@ -87,6 +87,9 @@ DEFINE_XEN_GUEST_HANDLE(physdev_set_iopl_t); /* * Set the current VCPU's I/O-port permissions bitmap. * @arg =3D=3D pointer to physdev_set_iobitmap structure. + * + * When @nr_ports is non-zero, Xen, like real CPUs and the TSS IOPB, always + * reads 2 bytes from @bitmap, which might be one byte beyond @nr_ports. */ #define PHYSDEVOP_set_iobitmap 7 struct physdev_set_iobitmap { --=20 2.39.5