Re: [PATCH v3 34/43] hw/intc: Add LoongArch extioi interrupt controller(EIOINTC)

[yangxiaojuan]

On 2022/5/12 上午9:58, maobibo wrote:
> 在 2022/5/11 22:14, Richard Henderson 写道:
> > On 5/11/22 02:54, yangxiaojuan wrote:
> > > On 2022/5/10 上午1:56, Richard Henderson wrote:
> > > > > > > +    case EXTIOI_IPMAP_START ... EXTIOI_IPMAP_END - 1:
> > > > > > > +        index = (offset - EXTIOI_IPMAP_START) >> 2;
> > > > > > > +        s->ipmap[index] = val;
> > > > > > > +        break;
> > > > > > Do you need to recompute the entire interrupt map when ipmap changes?
> > > > > Sorry, could you explain it in more detail? i can not understand the meanning 
> > > > > of 'the entire interrupt map'?
> > > > I mean, ipmap[*] and coremap[*] controls how isr[*] maps to the various cpus, 
> > > > as coreisr[*].  If either ipmap or coremap changes, do you need to re-compute 
> > > > coreisr[*] from the input isr[*]?
> > > I think the interrupt has been handled by the core before set coremap or ipmap, 
> > > and coreisr[*] also has been set and cleard by original core.
> > > So,  the new mapped core need not  to update the coreisr[*].
> >
> > Why do you believe that the core to which the interrupt is directed has 
> > interrupts enabled?  Why do you believe the core to which the interrupt is 
> > directed is the one that is changing the interrupt mapping?
I think there is no interrupt enable registers of percpu in extioi 
device. So, i think we need not to consider the core to which the 
interrupt is directed if has interrupts enabled.
If the core to which the interrupt is directed is diffrent from the core 
that is changing the mapping, Should we copy the status value of 
coreisr[old_core][irq_num] to coreisr[new_core][irq_num]?
Ip mapping could not affect coreisr[cpu][irq_num], Should we still need 
to update the interrupt?

Thanks.
xiaojuan
> By my understanding, irq bit of coreisr will be set even if the interrupt is 
> disabled on the core, interrupt has been posted to core already, only that it 
> is not serviced by the core. After irq affinity is changed, new interrupt may 
> arrived to new core, one interrupt will be serviced by old core and new core at 
> the same time. However it is the problem of guest kernel, guest kernel system 
> should disable the irq and wait until irq finishes to be serviced on the old 
> core when irq affinity is changing.
>
> > I think your assumption is not correct.
> >
> >
> > r~