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

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

On 16.11.24 12:01, Julien Grall wrote:
> 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...
The same applies regarding sending an event. I don't think the additional
setting of a bit is adding a relevant amount of processing time.

I agree that a limit is hard to find, but it could be rather high.

> So overall, I am not entirely convinced it is worth the trouble.
The only real reason I could see would be a setup without Xenstore. Reason
is that with Xenstore all interested parties could register a watch event
instead of directly consuming the VIRQ_DOM_EXC event.

We haven't needed multiple VIRQ_DOM_EXC consumers up to now, so I don't
think we should over-engineer the interface. At least there is a theoretical
solution for multiple consumers, so my patch series wouldn't introduce a
no-go for multiple consumers.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature