Re: [PATCH 2/6] xen: add bitmap to indicate per-domain state changes

[Julien Grall <julien@xxxxxxx>]

Hi Jan & Juergen,

On 04/11/2024 09:35, Jan Beulich wrote:
> On 01.11.2024 07:48, Jürgen Groß wrote:
> > On 31.10.24 11:59, Jan Beulich wrote:
> > > On 23.10.2024 15:10, Juergen Gross wrote:
> > > > Add a bitmap with one bit per possible domid indicating the respective
> > > > domain has changed its state (created, deleted, dying, crashed,
> > > > shutdown).
> > > >
> > > > Registering the VIRQ_DOM_EXC event will result in setting the bits for
> > > > all existing domains and resetting all other bits.
> > > That's furthering the "there can be only one consumer" model that also
> > > is used for VIRQ_DOM_EXC itself. I consider the existing model flawed
> > > (nothing keeps a 2nd party with sufficient privilege from invoking
> > > XEN_DOMCTL_set_virq_handler a 2nd time, taking away the notification
> > > from whoever had first requested it), and hence I dislike this being
> > > extended. Conceivably multiple parties may indeed be interested in
> > > this kind of information. At which point resetting state when the vIRQ
> > > is bound is questionable (or the data would need to become per-domain
> > > rather than global, or even yet more fine-grained, albeit
> > > ->virq_to_evtchn[] is also per-domain, when considering global vIRQ-s).
> > The bitmap is directly tied to the VIRQ_DOM_EXC anyway, as it is that
> > event which makes the consumer look into the bitmap via the new hypercall.
> >
> > If we decide to allow multiple consumers of VIRQ_DOM_EXC, we'll need to
> > have one bitmap per consumer of the event. This is not very hard to
> > modify.
While in principle I agree that having multiple consumers of 
VIRQ_DOM_EXC would be great. I have some scalability concern because now 
we would end up to have to update N bitmap every time. So we would need 
to put a limit to N. I don't think there is a good limit...
So overall, I am not entirely convinced it is worth the trouble.

Cheers,

--
Julien Grall