Re: Introduction of stable interface between Xenstore and hypervisor

[Julien Grall <julien@xxxxxxx>]

Hi Juergen,

On 10/09/2021 14:51, Juergen Gross wrote:
> On 10.09.21 15:49, Julien Grall wrote:
> > On 10/09/2021 14:46, Juergen Gross wrote:
> > > On 10.09.21 15:22, Jan Beulich wrote:
> > > > On 09.09.2021 08:27, Juergen Gross wrote:
> > > > > - Addition of a new stable hypercall ("get domain state") returning 
> > > > > the
> > > > >     following information:
> > > > >     + domid of a domain having the bit set in above bitmap
> > > > >     + state of that domain (existing, dying)
> > > > >     + sequence count of that domain
> > > > >     The related bit is reset in the bitmap as a side effect of the 
> > > > > call.
> > > > What I'd like us to consider up front is whether xenstored is going
> > > > to remain only entity interested in this kind of information. The
> > > > entire design looks to leverage that there's only a single consumer
> > > > in the system.
> > > Right. I'm just writing some RFC patches, and I have coded this
> > > interface to be usable only for the domain having VIRQ_DOM_EXC
> > > registered.
> > >
> > > The alternative (IMO) would have been to expose the domain-state
> > > bitmap to Xenstore (and/or other interested parties).
> > If we do that, let's do in such way that guest_*_bit() helpers are not 
> > necessary because they are a massive hammer on Arm. This means the 
> > bitmap would have to be read-only for the domain.
> I strongly prefer my current approach not needing a shared memory page.
That wasn't a way to say I prefer the shared bitmap. I wanted to point 
out that if this is the chosen approach then we ought to avoid using 
guest_*_bit().
I will be away for the next 4 weeks, so I preferred to mention it now to 
avoid the surprise of having yet another interface using guest_*_bit() 
when I am back :).
Cheers,

--
Julien Grall