Re: [RFC KERNEL PATCH v6 3/3] xen/privcmd: Add new syscall to get gsi from irq

[Jürgen Groß <jgross@xxxxxxxx>]

On 10.05.24 12:32, Chen, Jiqian wrote:
> On 2024/5/10 18:21, Jürgen Groß wrote:
> > On 10.05.24 12:13, Chen, Jiqian wrote:
> > > On 2024/5/10 17:53, Jürgen Groß wrote:
> > > > On 10.05.24 11:06, Chen, Jiqian wrote:
> > > > > Hi,
> > > > >
> > > > > On 2024/5/10 14:46, Jürgen Groß wrote:
> > > > > > On 19.04.24 05:36, Jiqian Chen wrote:
> > > > > > > +
> > > > > > > +    info->type = IRQT_PIRQ;
> > > > > I am considering whether I need to use a new type(like IRQT_GSI) here to 
> > > > > distinguish with IRQT_PIRQ, because function restore_pirqs will process all 
> > > > > IRQT_PIRQ.
> > > > restore_pirqs() already considers gsi == 0 to be not GSI related. Isn't this
> > > > enough?
> > > No, it is not enough.
> > > xen_pvh_add_gsi_irq_map adds the mapping of gsi and irq, but the value of gsi 
> > > is not 0,
> > > once restore_pirqs is called, it will do PHYSDEVOP_map_pirq for that gsi, but 
> > > in pvh dom0, we shouldn't do PHYSDEVOP_map_pirq.
> > Okay, then add a new flag to info->u.pirq.flags for that purpose?
> I feel like adding "new flag to info->u.pirq.flags" is not as good as adding " new type 
> to info->type".
> Because in restore_pirqs, it considers " info->type != IRQT_PIRQ", if adding " new flag 
> to info->u.pirq.flags", we need to add a new condition in restore_pirqs.
> And actually this mapping(gsi and irq of pvh) doesn't have pirq, so it is not 
> suitable to add to u.pirq.flags.
Does this mean there is no other IRQT_PIRQ related activity relevant for those
GSIs/IRQs? In that case I agree to add IRQT_GSI.


Juergen