On Sat, May 09, 2026 at 09:43:11AM +0900, Mark Brown wrote: > On Fri, May 08, 2026 at 06:12:01PM +0100, Mark Rutland wrote: > > On Fri, Mar 06, 2026 at 05:00:53PM +0000, Mark Brown wrote: > > > > Update the definition of SMIDR_EL1 in the sysreg definition to reflect the > > > information in DD0601 2025-06. This includes somewhat more generic ways of > > > describing the sharing of SMCUs, more information on supported priorities > > > and provides additional resolution for describing affinity groups. > > > FWIW, these are all in ARM DDI 0487 M.b: > > > https://developer.arm.com/documentation/ddi0487/mb/ > > > Is anything later in the series going to depend on these fields, or > > would everything behave correctly with the existing RES0 field > > definitions? > > We're exposing the affinity fields so there's a build time issue.
What I'm asking is what is the rationale for updating these definitions? e.g. * Are we planning to use any of the fields in a specific way in the *host*? * Are we planning to use any of the fields in a specific way in the *guest*? * Is this updated just out of habit? Knowing the rationale would help with review, even if that rationale is just "it seemed nice to use the latest". > > > +Field 55:52 HIP > > > Reading the ARM ARM, HIP is arguably a backwards-incompatible change. > > Yes, I belive people are aware. Ok. Is that considered a problem, or accepted? Which people are aware? > > Do we expect to expose that to VMs, or just hide priorities entirely? I > > suspect we probably want to require that the guest sees > > SMIDR_EL1.SMPS==0, and not care about any of that. > > Currently we're not exposing priority support to guests so we don't need > to worry about it yet. Do we plan to in future? Mark.
