|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 17/26] xen/riscv: introduce minimal virtual APLIC (vAPLIC) infrastructure
On 13.07.2026 11:57, Oleksii Kurochko wrote: > > > On 7/13/26 8:41 AM, Jan Beulich wrote: >> On 10.07.2026 17:52, Oleksii Kurochko wrote: >>> On 7/9/26 5:39 PM, Jan Beulich wrote: >>>> On 06.07.2026 17:57, Oleksii Kurochko wrote: >>>>> At the current development stage, only domain vINTC init and deinit >>>>> operations are required, so implement those first. >>>>> >>>>> Initialize vAPLIC's domaincfg to with the interrupt-enable bit set and >>>>> MSI delivery mode selected as the current solution is exepcted to have >>>>> always IMSIC, and initialize vintc->ops. >>>> >>>> How would domaincfg be initialized on real hardware? >>> >>> Xen will initialize that in aplic_init_hw_interrupts(): >>> writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg); >> >> I.e. it is very much something the OS should do. >> >>> I can see that maybe >>>> firmware would have to set DM suitably (and you may mean to take firmware's >>>> role here). >>> >>> I don't think that firmware will do that (and OpenSBI for example >>> doesn't do that). If firmware can do that we for sure want to control in >>> Xen what is written to ->domaincfg. >>> >>>> But isn't setting at least IE entirely the OSes responsibility? >>> >>> At least, Linux setups ->domaincfg once at the boot time: >>> >>> /* Setup APLIC domaincfg register */ >>> val = readl(priv->regs + APLIC_DOMAINCFG); >>> val |= APLIC_DOMAINCFG_IE; >>> if (msi_mode) >>> val |= APLIC_DOMAINCFG_DM; >>> writel(val, priv->regs + APLIC_DOMAINCFG); >>> if (readl(priv->regs + APLIC_DOMAINCFG) != val) >>> dev_warn(priv->dev, "unable to write 0x%x in domaincfg\n", val); >>> >>> And don't touch this register anymore, even for interrupt disablement it >>> isn't used. >>> >>> So Xen can just does once: >>> writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg); >>> >>> and then just properly handle access of a guest to domaincfg. >> >> Xen can do this for itself, sure. But shouldn't domaincfg as seen by guests >> start out 0 then? > > Now I think I understand your point. > > I agree that it should start from 0 (or from 0x80000000, since bits > 31:24 are read-only and fixed to 0x80). All other bits should be set or > cleared by the guest and written to vaplic->regs.domaincfg when the > guest accesses the vAPLIC domaincfg register. > > In that case, domain_vaplic_init() should initialize ->domaincfg as: > vaplic->regs.domaincfg = APLIC_DOMAINCFG_RO; > > instead of: > vaplic->regs.domaincfg = APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM | > APLIC_DOMAINCFG_RO; Yes. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |