From nobody Tue Feb 10 23:53:33 2026 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=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1770741433; cv=none; d=zohomail.com; s=zohoarc; b=VqpYS0j1KugCty1osvEz7d7qwp447rMIgZohP7DMv3wnNWzbPGJoetzI4vyIgr2Lpvg2fuckQMIEZoYv4DUHxFF/oRmxIGytr0xp5+Q35Nn+W93MUnRmhYbrPUT5Axz/tibQLn2YZJ0AxWPhf5afnQE31ofc9xrStcMwfG63b0c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1770741433; h=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=i83rk6CF00DSCAs1v5+Cc7fqBYd21dNjMT+muRCPfCk=; b=g5GuoUE86gfZ1NLwqY6VDiyW15tOtxqSlgBpfJ1UqvW1Law5VWkoxpNtFZqxursY4A8RA2FAM8ek69ilz5hLtJsNMMXHu4KaWnkSL68v0z0aLcEuuLY8bc9XSXAH34w/OEoEL2Kfjqgf4J0YQPPG45Hfie40hYprFjbq1A8oo4M= 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=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1770741433541953.2041776061648; Tue, 10 Feb 2026 08:37:13 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1226685.1533199 (Exim 4.92) (envelope-from ) id 1vpqjR-0001GX-2v; Tue, 10 Feb 2026 16:36:57 +0000 Received: by outflank-mailman (output) from mailman id 1226685.1533199; Tue, 10 Feb 2026 16:36:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vpqjQ-0001GH-UO; Tue, 10 Feb 2026 16:36:56 +0000 Received: by outflank-mailman (input) for mailman id 1226685; Tue, 10 Feb 2026 16:36:55 +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 1vpqjP-00012i-HU for xen-devel@lists.xenproject.org; Tue, 10 Feb 2026 16:36:55 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b501d82f-069e-11f1-9ccf-f158ae23cfc8; Tue, 10 Feb 2026 17:36:53 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4806ce0f97bso8989705e9.0 for ; Tue, 10 Feb 2026 08:36:53 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4834d5e11f5sm64803255e9.4.2026.02.10.08.36.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 08:36:52 -0800 (PST) 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: b501d82f-069e-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770741413; x=1771346213; 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=i83rk6CF00DSCAs1v5+Cc7fqBYd21dNjMT+muRCPfCk=; b=by6uynguHIjGrWENp+I/1R6DpXqVCTlnN/CV3KRFqo3if36VMHFJBb2hZ0e2mvIW4M q6ScIe3mWSW8HpLX9qSslzHUU4h9yIAMfSh6AjpKQhjGr4AgR/WP4VrEPtlLAObwIu1m yMRdBm1vVv3IceZvwj25ZcNVb3rBm8oF0b4lN6tBFRSbWc2PSRpo65msu5uDCq2tUsw6 pR/ZDshu7gpQW1gPjvvGWYpSosjIOm3K9AnLKa8LXwoZndyOU/ta1Z25PTjgmuS0QICg nbz/FgYEFEsCSQsuoqEj5w7Tzk5hPUfyrZaOIIbuWBGpCYP5Q7LEvRoxTawlnCkCDx9e +xTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770741413; x=1771346213; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=i83rk6CF00DSCAs1v5+Cc7fqBYd21dNjMT+muRCPfCk=; b=AQtPYQLZFjraQU1ZfdLnNeDZB8G09/8rFuH4BPZtVXts4/YqJUyiM5TZur49CctuQs B6iEmNDrzpP3C1fb63U1QYhf03pL2XZ4TBOY6uwMNTCy/oXkaSKA+IYpzOwrMrFURUAz /o6Z1nGYPt8+xtXxQKWvOasmR8KHcU3hdh+5t2Pc7oXFZE8tl82xXaAQHUTHDe6BtGif y+2J4M9tIFhhyPpkd6GYlbXiuFFc1UcnyCiAgdmhjwhqqmNnHOg87sJ1D1jcw8mSZgPu vjoVD0EH4pxN0cEQQyt1Hpk4KLgMlwldQx21SvYOkxnmCUqlF0lRUjk/PhSZF+zIpnh6 U9EQ== X-Gm-Message-State: AOJu0YxHCLQJd4ydzmoXyJmVbJVH2ml8EVGextLhmU6TmFCRzJ3Ib0XK 3JUGP+czKPC3gZvDeVtrlsDFlOWzyIjk1Ca4JLePpzwCjWd1EMqLM+TsoJXY6ifk X-Gm-Gg: AZuq6aJhjsrKNTw2Vkwa7ymnp+Ua4MwmMCBz+hltag6iEslEEW2WGafnYSKDjIKn+u5 u6SQXZyplKfARFVIZlAQ/W585NNEfM5DnJhMrTTVFX9XFpIgQOfGa1LjL4JLiItXPJdvjALHw7T 7/w6hFc2cSinD4dZun/wbrhAzSCaCF/TZYkvS5mCk3ypmcAN8ZxoBymYOv5nEu6PoT5ywqUWK8l JuFU7DQJPcS9PHnjB4L8YBAQwf6McROJNR9hk7SXabvhmePZqRaVqLS8L2Z3JbkLyXofIxavCxt MoxXn4UXMrmgOFvC2WPQJQfQ1Tw4J68BECORLHv7tWlJ8Hb2wRXf0/S8A4QZ1EWtG8U5N9reA/Q +NNrxMzvxtSj7pfqQCYOGR7uS/gHGIrr5GouGkbKzq98qLOVlz2mHk/7yUHfAzhMLMzznwGgoaz 4ZMBdsRa+hBxoTC2RThkB0bnBDdeL5KH+xprR+dHIMdhrMV/5H2Pi3tEiX5cTPSIXlHFHufofBJ V8b X-Received: by 2002:a05:600c:154b:b0:477:7925:f7fb with SMTP id 5b1f17b1804b1-483201e3e8amr206281615e9.10.1770741412614; Tue, 10 Feb 2026 08:36:52 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 1/2] xen/riscv: add support for local guest TLB flush using HFENCE.VVMA Date: Tue, 10 Feb 2026 17:36:40 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1770741436020154100 Content-Type: text/plain; charset="utf-8" Introduce flush_tlb_guest_local() to perform a local TLB flush of the guest= 's address space for the current hart. This leverages the RISC-V HFENCE.VVMA instruction, which is used to invalidate translations in the VS-stage of address translation. As for RISC-V binutils >=3D 2.39 is choosen, we can use hfence.vvma mnemoni= cs instead of defining hfence.vvma using .insn. Although it would be possible to use sbi_remote_hfence_vvma() for this purp= ose, it is unnecessary in this context since the flush is required only on the local hart. Using the SBI call would introduce additional overhead without benefit, resulting in unnecessary performance loss. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Add missed blanks in asm(). - Add operand modifier "z" and "J" constraint to be sure that zero register will be used when 0 is passed to HFENCE_VVMA(). --- xen/arch/riscv/include/asm/flushtlb.h | 7 +++++++ xen/arch/riscv/include/asm/insn-defs.h | 10 ++++++++++ 2 files changed, 17 insertions(+) create mode 100644 xen/arch/riscv/include/asm/insn-defs.h diff --git a/xen/arch/riscv/include/asm/flushtlb.h b/xen/arch/riscv/include= /asm/flushtlb.h index 4f64f9757058..b0112d416dbe 100644 --- a/xen/arch/riscv/include/asm/flushtlb.h +++ b/xen/arch/riscv/include/asm/flushtlb.h @@ -5,6 +5,7 @@ #include #include =20 +#include #include =20 struct page_info; @@ -14,6 +15,12 @@ static inline void local_hfence_gvma_all(void) asm volatile ( "hfence.gvma zero, zero" ::: "memory" ); } =20 +/* Flush VS-stage TLB for current hart. */ +static inline void flush_tlb_guest_local(void) +{ + HFENCE_VVMA(0, 0); +} + /* Flush TLB of local processor for address va. */ static inline void flush_tlb_one_local(vaddr_t va) { diff --git a/xen/arch/riscv/include/asm/insn-defs.h b/xen/arch/riscv/includ= e/asm/insn-defs.h new file mode 100644 index 000000000000..61aaa202fd13 --- /dev/null +++ b/xen/arch/riscv/include/asm/insn-defs.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef ASM_RISCV_INSN_DEFS_H +#define ASM_RISCV_INSN_DEFS_H + +#define HFENCE_VVMA(vaddr, asid) \ + asm volatile ( "hfence.vvma %z0, %z1" \ + :: "rJ" (vaddr), "rJ" (asid) : "memory" ) + +#endif /* ASM_RISCV_INSN_DEFS_H */ --=20 2.52.0 From nobody Tue Feb 10 23:53:33 2026 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=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1770741434; cv=none; d=zohomail.com; s=zohoarc; b=jLJqNND8Zgwi9YBoxtA6q0NrooM60ofT9fAoeDGaouOFx/IPdrdi0gDXxdxI8/7VGGkJEw4QJKM3M44wbrTR6M2kb/i93wtGoEudSj+LuYwtT5vUm09Xazm97rIgBwtbZs8TXDTdjUoHEkfrQuJ03A1S1gCb9TWMr/zEP6En4iI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1770741434; 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=JjEc9mDWav/qoIa1ZW+EtUPB2mySUlmztw5R2P/dXKI=; b=Uo/Cv6fRnK3qvRpZQah3zxad4a8/cRsjzrUBw4LNHejW9jkouQrqkhXZEyyrp5ZF5rTiYU5Q+qP3nGFOEia4MS0Cj/eul0VNexX5vjPR3icfRDqG82LFaGNO/biUGyWr6EBhaRD6gOD5JIwBPpGAX7ZXjoeDtGqJXBwq50sgGbQ= 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=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1770741434766934.3295028351707; Tue, 10 Feb 2026 08:37:14 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.1226686.1533204 (Exim 4.92) (envelope-from ) id 1vpqjR-0001J4-Da; Tue, 10 Feb 2026 16:36:57 +0000 Received: by outflank-mailman (output) from mailman id 1226686.1533204; Tue, 10 Feb 2026 16:36:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vpqjR-0001I3-5o; Tue, 10 Feb 2026 16:36:57 +0000 Received: by outflank-mailman (input) for mailman id 1226686; Tue, 10 Feb 2026 16:36:56 +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 1vpqjQ-00012i-IX for xen-devel@lists.xenproject.org; Tue, 10 Feb 2026 16:36:56 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b5af66a5-069e-11f1-9ccf-f158ae23cfc8; Tue, 10 Feb 2026 17:36:54 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-47ff94b46afso55972545e9.1 for ; Tue, 10 Feb 2026 08:36:54 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4834d5e11f5sm64803255e9.4.2026.02.10.08.36.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 08:36:53 -0800 (PST) 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: b5af66a5-069e-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770741414; x=1771346214; 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=JjEc9mDWav/qoIa1ZW+EtUPB2mySUlmztw5R2P/dXKI=; b=OZjnZeza4HclH6dSK8itrSbvark5ZCYAJEJJOxF7lZv12mum2VdoesyoGR0vy4Wgwg cCBAr118XDvw7oHFIJaEjmRBX2QWxg9zabHyfqmz1adxB9W0/AYZkCIZIWbDGA/OCCAd 90nGEhe/BY9Lf3oDYKYNucJkCjuDshzaBLPT7dltyNmTKKqGnr99rd21Cx1QLTKgyv2/ 3B5W2VHXDEpoFJ+hBduntz5n7QBgTG0Ekmt5d340Ggf24Rt5t9WdlXB0rG2cwE/R8HFv 6mhvehcZoWxOFPA659wN4SXbf4VsjzjW8xDOVWdCzd8cl+pTkcLX+fdyYNoR8Q+nqwTr UZXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770741414; x=1771346214; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=JjEc9mDWav/qoIa1ZW+EtUPB2mySUlmztw5R2P/dXKI=; b=m5EVdcLIa+FI5rmVct/35lM3h1/n5A3wd4N9TqIDb0OzT9k2s/9GiCcavnPLi7AMPb 5u1G1Sdcr+4zQUDXDFv3pX89X329gGqzWFS1FeOVwJss4gU9h8cQcasnLMtM1eDYPRAd u2OrXaileiqApFalb9J0kl8hZ7CyQbwiOztvyY6qgPmlBC+n5IFSzT7sdan5TZqQdGu9 bUxmJO/cNLQPb6hNpavT0ZDhnPHuOCbU6k2vem9h+AHi7RmS5kLuj9kz4dMETJFSONN2 DMwYimlvZBzaFRX+rMG8A+S02GJPJ/LYR3WIBLQi5z8vfzY9dAyC4gB6vHelPR5WFsZF 4sXA== X-Gm-Message-State: AOJu0YypVuxhTOOLSobodaeMW3D4ycrtC+p7b22BpBv4P6kbNHyD/0Jw tQXW3kAg+WJTWs3EJHHsXKb/HWeZLzhrLucmg/tjx8yPPjlGEK8R+QfpsirXjK6l X-Gm-Gg: AZuq6aIARFjmvZX/iL/5sjAWDrMPjSCQhcR3/xz4kT+KReXHeCs0AVSpMGPIGerH4Le J5rtV+ak8oPA5X8b9pQdLw3DVc41DQMxFn/djYaSTXQGiGl9/8DPMyqeNK9SpmWMAMgOZ5NxR1B e54iZa3jIhvbl6otFHt+rNR5JwXbBIiU26JLDHKPOAWrFjbzLFQZOKgqbCaQqwGFOJGUUTpsDyV 9Rz9tMYvR+Ck9e4xEWNfQ4FlCEWHeosxu/MyF/ecbaWaeokvO1f48y5EHQJJzyZfpRmew2r2LGf fNdSu8ze6GuIhSxY5WR9QNuG+p3FBgDt8nOlZNHZIpouATJDfdvk6PVqxdUHew+iTaYzBIp+URJ 0tCBUpILP/ULvh3K2gLIIz1/duhYYvbH2skqCpB2jfoAXtG1F2ewqAS6IIcFn5m8P8VvlTN81yR jL5/Tco4ar5764BqeoxqdukG4usVHAi3Ttrab3G+06GRGTXyyAaPKBx4RDHw17uWQUb0wCgQ== X-Received: by 2002:a05:600c:a59b:b0:471:793:e795 with SMTP id 5b1f17b1804b1-4834f38ff19mr24116555e9.0.1770741413865; Tue, 10 Feb 2026 08:36:53 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 2/2] xen/riscv: add p2m context switch handling for VSATP and HGATP Date: Tue, 10 Feb 2026 17:36:41 +0100 Message-ID: <0e6f450d64ce17f504d73c3429c8e8a9ced0cf06.1770739000.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1770741436104154100 Add helpers to safely update VS-stage and G-stage translation registers during vCPU context switches. Because VSATP and HGATP cannot be updated atomically, VSATP is cleared on switch-out to prevent speculative VS-stage translations being cached under an incorrect VMID. On VM entry, HGATP is reconstructed, VMID handling is performed, and VSATP is restored. This provides the necessary infrastructure for correct p2m context switching on RISC-V. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Add vsatp field declaration to arch_vcpu. - s/p2m_ctx_switch_{from,to}/p2m_ctxt_switch_{from,to}. - Introduce p2m_handle_vmenter() for proper handling of VMID, hgatp and vsatp updates. - Introduce is_p2m_switch_finished and init it inisde p2m_ctx_switch_to() for furhter handling in p2m_handle_vmenter(). - Code style fixes. - Add is_idle_vcpu() check in p2m_ctxt_switch_from(). - use csr_swap() in p2m_ctxt_switch_from(). - move flush_tlb_guest_local() to the end if p2m_handle_vmenter() and drop unnessary anymore comments. - Correct printk()'s arguments in p2m_handle_vmenter(). --- xen/arch/riscv/include/asm/domain.h | 1 + xen/arch/riscv/include/asm/p2m.h | 11 +++ xen/arch/riscv/p2m.c | 123 ++++++++++++++++++++++++++++ xen/arch/riscv/traps.c | 2 + 4 files changed, 137 insertions(+) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/a= sm/domain.h index b5a8a9f711ac..c029e50b96fe 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -59,6 +59,7 @@ struct arch_vcpu { register_t hstateen0; register_t hvip; =20 + register_t vsatp; register_t vsie; =20 /* diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/= p2m.h index f63b5dec99b1..0cdd3dc44683 100644 --- a/xen/arch/riscv/include/asm/p2m.h +++ b/xen/arch/riscv/include/asm/p2m.h @@ -90,6 +90,13 @@ struct p2m_domain { */ bool clean_dcache; =20 + /* + * Inidicate that context switch is fully finished. It is needed to + * detect in p2m_handle_vmenter() to undestand what to write to + * CSR_VSATP register. + */ + bool is_ctxt_switch_finished; + /* Highest guest frame that's ever been mapped in the p2m */ gfn_t max_mapped_gfn; =20 @@ -255,6 +262,10 @@ static inline bool p2m_is_locked(const struct p2m_doma= in *p2m) struct page_info *p2m_get_page_from_gfn(struct p2m_domain *p2m, gfn_t gfn, p2m_type_t *t); =20 +void p2m_ctxt_switch_from(struct vcpu *p); +void p2m_ctxt_switch_to(struct vcpu *n); +void p2m_handle_vmenter(void); + #endif /* ASM__RISCV__P2M_H */ =20 /* diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 0abeb374c110..275c38020ae2 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -1434,3 +1434,126 @@ struct page_info *p2m_get_page_from_gfn(struct p2m_= domain *p2m, gfn_t gfn, =20 return get_page(page, p2m->domain) ? page : NULL; } + +void p2m_ctxt_switch_from(struct vcpu *p) +{ + if ( is_idle_vcpu(p) ) + return; + + /* + * No mechanism is provided to atomically change vsatp and hgatp + * together. Hence, to prevent speculative execution causing one + * guest=E2=80=99s VS-stage translations to be cached under another gu= est=E2=80=99s + * VMID, world-switch code should zero vsatp, then swap hgatp, then + * finally write the new vsatp value what will be done in + * p2m_handle_vmenter(). + */ + p->arch.vsatp =3D csr_swap(CSR_VSATP, 0); + + /* + * Nothing to do with HGATP as it is constructed each time when + * p2m_handle_vmenter() is called. + */ +} + +void p2m_ctxt_switch_to(struct vcpu *n) +{ + if ( is_idle_vcpu(n) ) + return; + + n->domain->arch.p2m.is_ctxt_switch_finished =3D false; + + /* + * Nothing to do with HGATP or VSATP, they will be set in + * p2_handle_vmenter() + */ +} + +void p2m_handle_vmenter(void) +{ + struct p2m_domain *p2m =3D ¤t->domain->arch.p2m; + struct vcpu_vmid *p_vmid =3D ¤t->arch.vmid; + uint16_t old_vmid, new_vmid; + bool need_flush; + register_t vsatp_old =3D 0; + + BUG_ON(is_idle_vcpu(current)); + + /* + * No mechanism is provided to atomically change vsatp and hgatp + * together. Hence, to prevent speculative execution causing one + * guest=E2=80=99s VS-stage translations to be cached under another gu= est=E2=80=99s + * VMID, world-switch code should zero vsatp, then swap hgatp, then + * finally write the new vsatp value + * + * CSR_VSATP is already set to 0 in p2m_ctxt_switch_from() in the + * case when n->arch.is_p2m_switch_finished =3D false. Also, there is + * BUG_ON() below to verify that. + */ + if ( p2m->is_ctxt_switch_finished ) + vsatp_old =3D csr_swap(CSR_VSATP, 0); + + old_vmid =3D p_vmid->vmid; + need_flush =3D vmid_handle_vmenter(p_vmid); + new_vmid =3D p_vmid->vmid; + +#ifdef P2M_DEBUG + printk("%pv: oldvmid(%d) new_vmid(%d), need_flush(%d)\n", + current, old_vmid, new_vmid, need_flush); +#endif + + csr_write(CSR_HGATP, construct_hgatp(p2m_get_hostp2m(current->domain), + new_vmid)); + + if ( unlikely(need_flush) ) + local_hfence_gvma_all(); + + if ( p2m->is_ctxt_switch_finished ) + csr_swap(CSR_VSATP, vsatp_old); + /* + * We are not coming from a context switch here, so the VSATP valu= e is + * the same as it was before csr_swap() was executed at the start = of + * this function. Since VSATP was set to 0, no speculation could o= ccur, + * and the VS-stage TLB cannot be polluted. + * Therefore, no additional VS TLB flush is required. + */ + else + { + vsatp_old =3D csr_swap(CSR_VSATP, current->arch.vsatp); + + /* + * vsatp_old should be zero as in the case of context switch it was + * set to 0 in p2m_ctxt_switch_from(). + */ + BUG_ON(vsatp_old); + + p2m->is_ctxt_switch_finished =3D true; + + /* + * TODO: further investigation is needed here. + * + * In my opinion, a VS-stage TLB flush is not always strictly + * necessary. + * If a context switch occurs and VSATP is set to 0 before a= ny + * context-switch-related operations begin, no speculation c= an + * occur. Therefore, at the time this function executes, the + * VS-stage TLB should not be polluted with incorrect entries + * belonging to a previously running vCPU. Another one reaso= n is + * that about SATP register is mentioned the following in RI= SC-V + * spec: + * Changing satp.MODE from Bare to other modes and vice ve= rsa + * also takes effect immediately, without the need to exec= ute + * an SFENCE.VMA instruction. Likewise, changes to satp.AS= ID + * take effect immediately. + * I expect the same for VSATP (as it is VS copy of SATP) bu= t it + * isn't mentioned explicitly in the spec. + * + * The only case where a VS-stage TLB flush seems necessary = is + * when the VASID remains unchanged but VSATP is updated to = point + * to a different VS page table. In that case, flushing + * guarantees that the guest observes a clean context switch + * without any possibility of using stale TLB entries. + */ + flush_tlb_guest_local(); + } +} diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index e8d9ca902d9c..d6543eac1390 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -175,6 +175,8 @@ static void check_for_pcpu_work(void) vcpu_sync_interrupts(current); =20 vcpu_flush_interrupts(current); + + p2m_handle_vmenter(); } =20 static void timer_interrupt(void) --=20 2.52.0