Re: [PATCH v2 1/2] restrict concept of pIRQ to x86

[Julien Grall <julien@xxxxxxx>]

Hi,

On 04/05/2023 09:21, Jan Beulich wrote:
> On 04.05.2023 10:13, Roger Pau Monné wrote:
> > On Thu, May 04, 2023 at 09:50:27AM +0200, Jan Beulich wrote:
> > > On 04.05.2023 09:44, Roger Pau Monné wrote:
> > > > On Wed, May 03, 2023 at 05:33:05PM +0200, Jan Beulich wrote:
> > > > > --- a/xen/include/xen/sched.h
> > > > > +++ b/xen/include/xen/sched.h
> > > > > @@ -438,12 +438,14 @@ struct domain
> > > > >   
> > > > >       struct grant_table *grant_table;
> > > > >   
> > > > > +#ifdef CONFIG_HAS_PIRQ
> > > > >       /*
> > > > >        * Interrupt to event-channel mappings and other per-guest-pirq data.
> > > > >        * Protected by the domain's event-channel spinlock.
> > > > >        */
> > > > >       struct radix_tree_root pirq_tree;
> > > > >       unsigned int     nr_pirqs;
> > > > > +#endif
> > > > Won't it be cleaner to just move this into arch_domain and avoid a
> > > > bunch of the ifdefary? As the initialization of the fields would be
> > > > moved to arch_domain_create() also.
> > > That's hard to decide without knowing what e.g. RISC-V is going to
> > > want. Taking (past) IA-64 into consideration - that would likely
> > > have wanted to select this new HAS_PIRQ, and hence keeping these
> > > pieces where they are imo makes sense.
> > I'm kind of confused, what does Arm do here?  AFAICT the pirq_tree is
> > used by both PV and HVM guests in order to store the native interrupt
> > -> guest interrupt translation, doesn't Arm also need something
> > similar?
> According to [1] they don't, hence the (new in v2) change here. Aiui
> they simply map IRQ to pIRQ 1:1.
The vGIC is able to cope with vIRQ != pIRQ. But so far, we only allow a 
domain to map 1:1.
For that we are storing the pIRQ to vIRQ mapping in the IRQ desc and 
have a pointer to the desc in the vIRQ information.
So no need to a PIRQ tree on the Arm side.

Cheers,

--
Julien Grall