From: Jan Beulich <jbeulich@suse.com>
To: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Cc: "Romain Caritey" <Romain.Caritey@microchip.com>,
"Baptiste Le Duc" <baptiste.le-duc@vates.tech>,
"Zheng Zhang" <zhangzheng@iscas.ac.cn>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Connor Davis" <connojdavis@gmail.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger@xenproject.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 24/39] xen/riscv: add helpers for decoding a trapped load or store
Date: Mon, 14 Sep 2026 13:03:13 +0200 [thread overview]
Message-ID: <895a427d-1adb-43cb-a2bb-e0e9d50791db@suse.com> (raw)
In-Reply-To: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com>
On 27.08.2026 17:21, Oleksii Kurochko wrote:
> emulate_load() and emulate_store() will both need to obtain the
> instruction which caused a guest MMIO trap, decode it, and locate the
> register operand it names. Add what the two share, ahead of either of
> them being implemented: struct decoded_insn, insn_fetch_faulted(),
> decode_ldst_insn(), guest_xlen(), guest_gpr() and advance_pc().
>
> The mask/match chain is adapted from Linux's KVM RISC-V implementation.
>
> Nothing calls any of this yet, so tag the functions __maybe_unused to
> keep the build going; the tags go away once emulate_load() and
> emulate_store() gain their bodies later.
That'll be a lot of churn to drop those __maybe_unused again. As this
is merely transient, did you consider putting
(void)is_load_guest_page_fault;
etc in e.g. emulate_load()?
> @@ -13,9 +14,29 @@
> #include <asm/csr.h>
> #include <asm/current.h>
> #include <asm/emulate.h>
> +#include <asm/guest_access.h>
> +#include <asm/processor.h>
> #include <asm/riscv_encoding.h>
> #include <asm/traps.h>
>
> +/*
> + * Determine the trapped load or store instruction which caused a guest MMIO
> + * trap.
> + */
> +struct decoded_insn {
> + /* The instruction itself, and its length in bytes. */
> + unsigned long insn;
> + unsigned int insn_len;
> + /* Width of the memory access, in bytes. */
> + unsigned int len;
> + /* Number of the register operand: rd for a load, rs2 for a store. */
> + unsigned int reg;
> + /* The access is a store rather than a load. */
> + bool is_write;
> + /* The load zero-extends its result rather than sign-extending it. */
> + bool is_unsigned;
> +};
I wonder how efficient this is. With use of bitfield the size of this struct
can likely be more than halved. With suitable choice of widths this may not
even cause significantly worse generated code.
One thing in any event: Why would the insn field need to be wider than 32
bits?
> @@ -39,6 +60,71 @@ struct guest_fault {
> paddr_t gpa;
> };
>
> +static bool is_load_guest_page_fault(unsigned long scause)
> +{
> + return scause == CAUSE_LOAD_GUEST_PAGE_FAULT;
> +}
With no "store" counterpart this may end up being a little fragile (at the
use site(s)).
> +/*
> + * The effective XLEN of the guest at the point of the trap: hstatus.VSXL for a
> + * trap taken from VS-mode, vsstatus.UXL for one taken from VU-mode.
> + *
> + * VSXL is consulted whichever mode the trap came from, as it also gives the
> + * width of vsstatus itself: where VSXL says 32, that register has no UXL field
> + * to consult and VU-mode is 32-bit as well, there being nothing to configure.
> + *
> + * It is needed to decode a trapped instruction: the encodings which exist only
> + * for XLEN=64 must not be recognized for a 32-bit guest. Besides those simply
> + * being reserved there, the compressed ones are ambiguous: C.LD and C.FLW
> + * share the encoding 0x6000 (mask 0xe003), and likewise C.SD/C.FSW,
> + * C.LDSP/C.FLWSP and C.SDSP/C.FSWSP.
> + *
> + * IS_ENABLED() can't be used here as HSTATUS_VSXL is defined for
> + * __riscv_xlen == 64 only, the field not existing on RV32 in the first place.
> + */
> +static __maybe_unused unsigned int guest_xlen(const struct cpu_user_regs *regs)
> +{
> +#ifdef CONFIG_RISCV_32
> + return 32;
> +#else
> + unsigned long xl = MASK_EXTR(regs->hstatus, HSTATUS_VSXL);
> +
> + if ( (xl == XLEN_FIELD_64) && !(regs->sstatus & SSTATUS_SPP) )
How about xl > XLEN_FIELD_32 here, to be RV128-compatible?
> @@ -87,6 +173,250 @@ static void resolve_faulting_gpa(struct guest_fault *gf)
> (htinst_is_pseudo(gf->htinst) ? 0 : (gf->stval & 3));
> }
>
> +/*
> + * Where the value of a decoded instruction's register operand is held.
> + *
> + * Relies on x0..x31 being laid out at the start of struct cpu_user_regs in
> + * architectural register-number order; see the comment there.
> + */
> +static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs,
> + unsigned int reg)
> +{
> + ASSERT(reg < 32);
> +
> + return REG_PTR(reg, 0, regs);
> +}
For future callers of this: For 32-bit environments hardware guarantees
upper halves of registers to be zero?
> +/*
> + * Obtain the instruction which caused a guest MMIO trap, filling in
> + * @di->insn and @di->insn_len. It either comes transformed in htinst, or has
> + * to be fetched from guest memory.
> + *
> + * Returns true if the fetch faulted in turn; the resulting trap has then
> + * already been redirected to the guest and there is nothing further for the
> + * caller to do. Where it returns false, @di has been filled in and emulation
> + * is to continue.
> + */
> +static bool __maybe_unused insn_fetch_faulted(const struct guest_fault *gf,
> + struct decoded_insn *di)
> +{
> + unsigned long htinst = gf->htinst;
> +
> + /*
> + * A pseudoinstruction says nothing about the instruction the guest was
> + * executing, and comes with a guest physical address which isn't the one
> + * that instruction accessed. handle_guest_page_fault() deals with such a
> + * fault on its own, so no emulation can ever start for one.
> + */
> + ASSERT(!htinst_is_pseudo(htinst));
> +
> + if ( htinst & BIT(0, UL) )
> + {
> + /*
> + * Bit[0] == 1 implies trapped instruction value is
> + * transformed instruction or custom instruction.
> + *
> + * The transformation always yields the 32-bit format, with bits[1:0]
> + * holding a marker instead of the original opcode bits: bit[0] set to
> + * flag the transformation, bit[1] clear if the trapped instruction
> + * was a compressed one. Restoring the opcode bits makes the value the
> + * valid 32-bit encoding decode_ldst_insn() matches against. Its
> + * INSN_MASK_C_* cases exist for the branch below, where a compressed
> + * instruction is read from guest memory as is: a trapped one arrives
> + * here already expanded to its 32-bit equivalent, and the opcode bits
> + * just restored keep it from matching those cases anyway.
> + *
> + * The length then cannot come from the value anymore, only from
> + * bit[1]. And only a 16- or a 32-bit instruction is ever reported
> + * this way: the standard load and store instructions the hardware
> + * transforms are all of one of these two lengths, anything else comes
> + * as the zero special value handled below.
> + */
> + di->insn = htinst | INSN_16BIT_MASK;
> + di->insn_len = (htinst & BIT(1, UL)) ? 4 : 2;
Hmm, so ->insn_len doesn't describe ->insn, as suggested by the comment in
the struct. That wants clarifying there.
> + }
> + else
> + {
> + const struct cpu_user_regs *regs = gf->regs;
> + struct trap_info utrap = {};
> +
> + /*
> + * Bit[0] == 0 implies trapped instruction value is
> + * zero or special value. With the pseudoinstructions ruled out
> + * above, only zero is left: the instruction has to be read from
> + * guest memory.
> + */
> +
> + di->insn = riscv_read_guest(regs->sepc, true, &utrap);
> + if ( utrap.scause )
> + {
> + /*
> + * If during getting of trapped instruction a fault happen in
> + * G-stage translation then CAUSE_LOAD_GUEST_PAGE_FAULT is
> + * generated. Such faults during this operation is considered as
> + * bus error.
> + */
> + if ( is_load_guest_page_fault(utrap.scause) )
> + utrap.scause = CAUSE_FETCH_ACCESS;
> +
> + utrap.sepc = regs->sepc;
Couldn't this be part of the initializer of utrap? Or does read_guest()
alter the field?
> + trap_redirect(&utrap);
> +
> + return true;
> + }
> +
> + /*
> + * riscv_read_guest() fetches at most two halfwords, so a wider
> + * encoding has been read in part only and cannot be decoded here.
> + *
> + * Report an illegal instruction, which is what the guest would have
> + * got for such an encoding anyway: the ISA defines no instruction
> + * wider than 32 bits.
> + */
Such wording is at risk of going stale. Better say that no guest-exposed
extensions have wider than 32-bit insns.
> + if ( !INSN_IS_16BIT(di->insn) && !INSN_IS_32BIT(di->insn) )
> + {
> + utrap.sepc = regs->sepc;
With the earlier remark this may then also not be needed here.
> + utrap.scause = CAUSE_ILLEGAL_INSTRUCTION;
> + /*
> + * stval is left zero: the spec allows that for an illegal
> + * instruction, and only part of the instruction is in hand.
> + */
Not just this - stval may also not be wide enough to hold the full insn.
> + trap_redirect(&utrap);
> +
> + return true;
> + }
> +
> + di->insn_len = INSN_LEN(di->insn);
If you moved this up a little, you could avoid the separate use of
INSN_{32,64}BIT_MASK above, by going from the value calculated here.
> + }
> +
> + return false;
> +}
> +
> +/*
> + * Decode the load or store instruction fetched into @di, filling in the
> + * remaining fields of it (@di->insn and @di->insn_len are filled by
> + * insn_fetch_faulted()).
> + *
> + * @xlen is the effective XLEN of the guest, needed as
> + * the encodings which exist for XLEN=64 only must not be recognized for a
> + * 32-bit guest.
> + *
> + * Returns false if the instruction is not a load or store which can be
> + * emulated here.
> + */
> +static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di,
> + unsigned int xlen)
> +{
> + unsigned long insn = di->insn;
> + /* Register fields of the uncompressed forms ... */
> + unsigned int rd = RV_RD(insn);
> + unsigned int rs2 = RV_RS2(insn);
> + /*
> + * ... and of the compressed ones, where the 3-bit field selects one of
> + * x8..x15, while the stack-pointer-relative forms have a full-width one.
> + */
> + unsigned int rs2s = RVC_RS2S(insn);
> + unsigned int rs2c = RVC_RS2(insn);
> +
> + di->is_write = false;
> + di->is_unsigned = false;
Elsewhere we established that the whole struct has to start out zeroed.
Why not leverage that also here?
> + di->reg = rd;
> +
> + if ( (insn & INSN_MASK_LB) == INSN_MATCH_LB )
> + di->len = 1;
> + else if ( (insn & INSN_MASK_LBU) == INSN_MATCH_LBU )
> + {
> + di->len = 1;
> + di->is_unsigned = true;
> + }
> + else if ( (insn & INSN_MASK_LH) == INSN_MATCH_LH )
> + di->len = 2;
> + else if ( (insn & INSN_MASK_LHU) == INSN_MATCH_LHU )
> + {
> + di->len = 2;
> + di->is_unsigned = true;
> + }
> + else if ( (insn & INSN_MASK_LW) == INSN_MATCH_LW )
> + di->len = 4;
> + else if ( xlen == 64 && (insn & INSN_MASK_LWU) == INSN_MATCH_LWU )
> + {
> + di->len = 4;
> + di->is_unsigned = true;
> + }
> + else if ( (insn & INSN_MASK_C_LW) == INSN_MATCH_C_LW )
> + {
> + di->len = 4;
> + di->reg = rs2s;
> + }
These insns encode the access width uniformly, i.e. doing things the
way done above is rather inefficient.
> + /* c.lwsp and c.ldsp are reserved with rd being x0. */
> + else if ( (insn & INSN_MASK_C_LWSP) == INSN_MATCH_C_LWSP && rd )
> + di->len = 4;
Careful with insns not part of the base ISA: Between the trap and you
getting to fetch and decode, the in-memory insn may have changed. You
posibly set yourself up for vulnerabilities if you permit C encodings
for guests not having C exposed to them.
Jan
next prev parent reply other threads:[~2026-09-14 11:03 UTC|newest]
Thread overview: 251+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 15:20 [PATCH v2 00/39] [RISC-V] virtual interrupt controller (vAPLIC/vIMSIC) support Oleksii Kurochko
2026-08-27 15:20 ` [PATCH v2 01/39] xen/riscv: drop pregs from struct cpu_user_regs Oleksii Kurochko
2026-08-31 12:48 ` Baptiste Le Duc
2026-09-01 6:58 ` Jan Beulich
2026-08-27 15:20 ` [PATCH v2 02/39] xen/riscv: drop bug.h's duplicate instruction length helpers Oleksii Kurochko
2026-08-31 12:48 ` Baptiste Le Duc
2026-09-01 7:01 ` Jan Beulich
2026-09-02 10:48 ` Oleksii Kurochko
2026-09-02 13:02 ` Jan Beulich
2026-09-02 13:45 ` Oleksii Kurochko
2026-09-02 14:27 ` Jan Beulich
2026-08-27 15:20 ` [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL Oleksii Kurochko
2026-08-31 12:48 ` Baptiste Le Duc
2026-09-01 7:03 ` Jan Beulich
2026-09-01 8:40 ` Oleksii Kurochko
2026-09-01 15:16 ` Jan Beulich
2026-09-01 15:20 ` Jan Beulich
2026-09-02 11:42 ` Oleksii Kurochko
2026-09-02 13:07 ` Jan Beulich
2026-09-02 13:29 ` Oleksii Kurochko
2026-09-02 14:31 ` Jan Beulich
2026-09-02 15:17 ` Oleksii Kurochko
2026-09-02 15:56 ` Oleksii Kurochko
2026-09-02 17:45 ` Oleksii Kurochko
2026-08-27 15:20 ` [PATCH v2 04/39] xen/riscv: introduce csr_read64() Oleksii Kurochko
2026-08-27 15:36 ` Andrew Cooper
2026-08-31 12:42 ` Oleksii Kurochko
2026-09-01 7:07 ` Jan Beulich
2026-08-27 15:20 ` [PATCH v2 05/39] xen/riscv: request a G-stage flush on vmenter when VMIDs are disabled Oleksii Kurochko
2026-08-31 12:48 ` Baptiste Le Duc
2026-09-01 8:43 ` Oleksii Kurochko
2026-08-27 15:20 ` [PATCH v2 06/39] xen/riscv: use UINT64_MAX to disable the VS-timer Oleksii Kurochko
2026-08-31 12:48 ` Baptiste Le Duc
2026-09-01 7:12 ` Jan Beulich
2026-09-01 8:47 ` Oleksii Kurochko
2026-08-27 15:20 ` [PATCH v2 07/39] xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h Oleksii Kurochko
2026-09-01 15:36 ` Baptiste Le Duc
2026-09-01 15:53 ` Jan Beulich
2026-09-02 13:22 ` Jan Beulich
2026-09-02 13:52 ` Oleksii Kurochko
2026-08-27 15:20 ` [PATCH v2 08/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch Oleksii Kurochko
2026-09-01 15:36 ` Baptiste Le Duc
2026-09-03 10:28 ` Oleksii Kurochko
2026-09-09 13:24 ` Jan Beulich
2026-09-09 14:04 ` Oleksii Kurochko
2026-09-09 14:32 ` Jan Beulich
2026-08-27 15:20 ` [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation Oleksii Kurochko
2026-09-02 11:51 ` Baptiste Le Duc
2026-09-04 11:58 ` Oleksii Kurochko
2026-09-04 12:03 ` Jan Beulich
2026-09-02 12:31 ` Baptiste Le Duc
2026-09-04 14:02 ` Oleksii Kurochko
2026-09-09 14:26 ` Jan Beulich
2026-09-10 10:37 ` Oleksii Kurochko
2026-09-10 11:14 ` Jan Beulich
2026-09-10 14:24 ` Oleksii Kurochko
2026-09-12 8:50 ` SeungJu Cheon
2026-09-22 8:50 ` Oleksii Kurochko
2026-08-27 15:20 ` [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() Oleksii Kurochko
2026-09-04 8:26 ` Baptiste Le Duc
2026-09-04 14:28 ` Oleksii Kurochko
2026-09-09 14:51 ` Jan Beulich
2026-09-09 14:52 ` Jan Beulich
2026-09-10 10:59 ` Oleksii Kurochko
2026-09-10 11:23 ` Jan Beulich
2026-09-10 12:44 ` Oleksii Kurochko
2026-09-10 12:57 ` Jan Beulich
2026-09-11 9:47 ` Oleksii Kurochko
2026-09-10 11:23 ` Jan Beulich
2026-08-27 15:20 ` [PATCH v2 11/39] xen/riscv: add helper to check APLIC MSI mode Oleksii Kurochko
2026-09-04 8:26 ` Baptiste Le Duc
2026-09-09 14:53 ` Jan Beulich
2026-08-27 15:20 ` [PATCH v2 12/39] xen/riscv: implement vCPU context switching Oleksii Kurochko
2026-09-02 14:42 ` Oleksii Kurochko
2026-09-04 8:26 ` Baptiste Le Duc
2026-09-04 8:33 ` Jan Beulich
2026-09-04 9:54 ` Baptiste Le Duc
2026-09-04 14:55 ` Oleksii Kurochko
2026-09-07 8:17 ` Jan Beulich
2026-09-08 9:06 ` Oleksii Kurochko
2026-09-05 7:25 ` Oleksii Kurochko
2026-09-10 13:29 ` Jan Beulich
2026-09-11 10:43 ` Oleksii Kurochko
2026-08-27 15:20 ` [PATCH v2 13/39] xen/riscv: save and restore AIA state on vCPU context switch Oleksii Kurochko
2026-09-04 9:52 ` Baptiste Le Duc
2026-09-04 16:40 ` Oleksii Kurochko
2026-08-27 15:20 ` [PATCH v2 14/39] xen/riscv: introduce vintc_ctxt_switch_{from,to}() Oleksii Kurochko
2026-09-04 11:25 ` Baptiste Le Duc
2026-09-04 16:54 ` Oleksii Kurochko
2026-09-10 14:54 ` Jan Beulich
2026-08-27 15:20 ` [PATCH v2 15/39] xen/riscv: add IMSIC vCPU context switch handlers Oleksii Kurochko
2026-09-04 11:33 ` Baptiste Le Duc
2026-09-04 16:56 ` Oleksii Kurochko
2026-09-10 14:57 ` Jan Beulich
2026-09-11 11:19 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields Oleksii Kurochko
2026-09-07 15:57 ` Baptiste Le Duc
2026-09-08 6:06 ` Jan Beulich
2026-09-08 8:18 ` Baptiste Le Duc
2026-09-08 9:19 ` Oleksii Kurochko
2026-09-08 16:26 ` Baptiste Le Duc
2026-09-08 13:44 ` Jan Beulich
2026-09-09 11:20 ` Oleksii Kurochko
2026-09-09 12:22 ` Jan Beulich
2026-09-09 12:42 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 17/39] xen/riscv: decouple INSN_PSEUDO_VS_* from the hypervisor's XLEN Oleksii Kurochko
2026-09-07 15:57 ` Baptiste Le Duc
2026-09-08 9:34 ` Oleksii Kurochko
2026-09-08 16:04 ` Baptiste Le Duc
2026-09-09 12:57 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 18/39] xen/riscv: add guest page fault handling stub Oleksii Kurochko
2026-09-07 15:57 ` Baptiste Le Duc
2026-09-08 9:49 ` Oleksii Kurochko
2026-09-08 14:10 ` Jan Beulich
2026-09-09 15:09 ` Oleksii Kurochko
2026-09-10 6:38 ` Jan Beulich
2026-09-11 11:47 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest Oleksii Kurochko
2026-09-07 15:57 ` Baptiste Le Duc
2026-09-08 10:01 ` Oleksii Kurochko
2026-09-08 14:58 ` Oleksii Kurochko
2026-09-08 15:05 ` Jan Beulich
2026-09-08 15:47 ` Baptiste Le Duc
2026-09-08 15:58 ` Jan Beulich
2026-09-08 14:16 ` Jan Beulich
2026-09-08 14:16 ` Jan Beulich
2026-09-08 15:25 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 20/39] xen/riscv: detect Shtvala Oleksii Kurochko
2026-09-07 15:57 ` Baptiste Le Duc
2026-09-08 10:15 ` Oleksii Kurochko
2026-09-08 15:49 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 21/39] xen/riscv: resolve the faulting guest physical address Oleksii Kurochko
2026-09-09 12:04 ` Baptiste Le Duc
2026-09-11 12:56 ` Oleksii Kurochko
2026-09-10 15:06 ` Jan Beulich
2026-08-27 15:21 ` [PATCH v2 22/39] xen/riscv: add guest memory read helper Oleksii Kurochko
2026-09-09 12:04 ` Baptiste Le Duc
2026-09-10 15:19 ` Jan Beulich
2026-09-11 13:06 ` Oleksii Kurochko
2026-09-11 13:41 ` Oleksii Kurochko
2026-09-11 13:47 ` Jan Beulich
2026-09-11 13:50 ` Oleksii Kurochko
2026-09-10 15:28 ` Jan Beulich
2026-09-11 13:57 ` Oleksii Kurochko
2026-09-11 14:00 ` Jan Beulich
2026-09-11 14:29 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 23/39] xen/riscv: look up the exception table for any trap taken in Xen context Oleksii Kurochko
2026-09-10 15:31 ` Jan Beulich
2026-09-18 8:44 ` Baptiste Le Duc
2026-09-22 9:31 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 24/39] xen/riscv: add helpers for decoding a trapped load or store Oleksii Kurochko
2026-09-14 11:03 ` Jan Beulich [this message]
2026-09-14 15:57 ` Oleksii Kurochko
2026-09-15 5:18 ` Jan Beulich
2026-09-18 8:44 ` Baptiste Le Duc
2026-09-22 11:03 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 25/39] xen/riscv: add guest load emulation for trapped MMIO accesses Oleksii Kurochko
2026-09-14 11:48 ` Jan Beulich
2026-09-16 4:16 ` Oleksii Kurochko
2026-09-18 9:16 ` Baptiste Le Duc
2026-09-22 11:22 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 26/39] xen/riscv: add guest store " Oleksii Kurochko
2026-09-14 12:01 ` Jan Beulich
2026-09-16 4:53 ` Oleksii Kurochko
2026-09-16 5:15 ` Jan Beulich
2026-09-16 5:23 ` Oleksii Kurochko
2026-09-18 9:16 ` Baptiste Le Duc
2026-09-22 11:38 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 27/39] xen/riscv: introduce arch_move_irqs() Oleksii Kurochko
2026-09-14 12:07 ` Jan Beulich
2026-09-16 5:32 ` Oleksii Kurochko
2026-09-22 17:00 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed Oleksii Kurochko
2026-09-14 12:12 ` Jan Beulich
2026-09-16 5:55 ` Oleksii Kurochko
2026-09-16 13:02 ` Jan Beulich
2026-09-17 5:12 ` Oleksii Kurochko
2026-09-17 5:20 ` Jan Beulich
2026-09-17 8:40 ` Oleksii Kurochko
2026-09-17 10:41 ` Jan Beulich
2026-09-18 9:21 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 29/39] xen/riscv: introduce aplic_reconfigure_target() Oleksii Kurochko
2026-09-14 12:25 ` Jan Beulich
2026-09-17 4:55 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file Oleksii Kurochko
2026-09-14 13:13 ` Jan Beulich
2026-09-17 14:50 ` Oleksii Kurochko
2026-09-18 6:02 ` Jan Beulich
2026-09-21 16:15 ` Baptiste Le Duc
2026-09-22 6:32 ` Jan Beulich
2026-09-22 13:01 ` Oleksii Kurochko
2026-09-22 15:36 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration Oleksii Kurochko
2026-09-14 13:27 ` Jan Beulich
2026-09-18 11:53 ` Oleksii Kurochko
2026-09-22 17:03 ` Baptiste Le Duc
2026-09-22 17:00 ` Baptiste Le Duc
2026-09-22 18:48 ` Oleksii Kurochko
2026-09-23 10:57 ` Oleksii Kurochko
2026-09-23 12:15 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file Oleksii Kurochko
2026-09-14 15:02 ` Jan Beulich
2026-09-21 8:03 ` Oleksii Kurochko
2026-09-21 8:28 ` Jan Beulich
2026-09-21 8:50 ` Oleksii Kurochko
2026-09-23 13:34 ` Baptiste Le Duc
2026-09-23 15:45 ` Oleksii Kurochko
2026-09-23 16:10 ` Baptiste Le Duc
2026-09-23 15:25 ` Baptiste Le Duc
2026-09-23 15:48 ` Oleksii Kurochko
2026-09-23 16:11 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory Oleksii Kurochko
2026-09-14 15:15 ` Jan Beulich
2026-09-21 9:51 ` Oleksii Kurochko
2026-09-23 15:15 ` Baptiste Le Duc
2026-09-23 16:02 ` Oleksii Kurochko
2026-09-23 16:16 ` Baptiste Le Duc
2026-09-23 18:30 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 34/39] xen/riscv: restore register state in the new IMSIC VS-file Oleksii Kurochko
2026-09-14 15:21 ` Jan Beulich
2026-09-21 10:58 ` Oleksii Kurochko
2026-09-23 15:42 ` Baptiste Le Duc
2026-09-23 16:08 ` Oleksii Kurochko
2026-09-23 16:21 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 35/39] xen/riscv: add basic VGEIN management for AIA guests Oleksii Kurochko
2026-09-18 12:38 ` Jan Beulich
2026-09-23 16:06 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt Oleksii Kurochko
2026-09-18 12:52 ` Jan Beulich
2026-09-21 14:01 ` Oleksii Kurochko
2026-09-21 15:08 ` Jan Beulich
2026-09-22 13:37 ` Oleksii Kurochko
2026-09-24 14:25 ` Baptiste Le Duc
2026-09-25 15:33 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 37/39] xen/riscv: map IMSIC interrupt file for vCPUs Oleksii Kurochko
2026-09-21 11:36 ` Jan Beulich
2026-09-21 14:35 ` Oleksii Kurochko
2026-09-25 9:22 ` Baptiste Le Duc
2026-08-27 15:21 ` [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu() Oleksii Kurochko
2026-09-21 12:12 ` Jan Beulich
2026-09-22 8:23 ` Oleksii Kurochko
2026-09-22 10:20 ` Jan Beulich
2026-09-22 13:58 ` Oleksii Kurochko
2026-09-25 9:22 ` Baptiste Le Duc
2026-09-25 11:26 ` Oleksii Kurochko
2026-08-27 15:21 ` [PATCH v2 39/39] xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu Oleksii Kurochko
2026-09-21 12:32 ` Jan Beulich
2026-09-22 8:31 ` Oleksii Kurochko
2026-09-22 10:23 ` Jan Beulich
2026-09-25 13:11 ` Baptiste Le Duc
2026-09-28 11:01 ` Oleksii Kurochko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=895a427d-1adb-43cb-a2bb-e0e9d50791db@suse.com \
--to=jbeulich@suse.com \
--cc=Romain.Caritey@microchip.com \
--cc=alistair.francis@wdc.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=baptiste.le-duc@vates.tech \
--cc=connojdavis@gmail.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=oleksii.kurochko@gmail.com \
--cc=roger@xenproject.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=zhangzheng@iscas.ac.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox