RE: [PATCH v5 1/4] domctl: introduce a new domain create flag, XEN_DOMCTL_CDF_evtchn_fifo, ...

[Paul Durrant <xadimgnik@gmail.com>]

> -----Original Message-----
[snip]
> >>>>
> >>>> All of the hunks above point out a scalability issue if we were to
> >>>> follow this route for even just a fair part of new sub-ops, and I
> >>>> suppose you've noticed this with the next patch presumably touching
> >>>> all the same places again.
> >>>
> >>> Indeed. This solution works for now but is probably not what we want in the long run. Same goes
> for
> >> the current way we control viridian features via an HVM param. It is good enough for now IMO since
> >> domctl is not a stable interface. Any ideas about how we might implement a better interface in the
> >> longer term?
> >>
> >> While it has other downsides, Jürgen's proposal doesn't have any
> >> similar scalability issue afaics. Another possible model would
> >> seem to be to key new hypercalls to hypervisor CPUID leaf bits,
> >> and derive their availability from a guest's CPUID policy. Of
> >> course this won't work when needing to retrofit guarding like
> >> you want to do here.
> >>
> >
> > Ok, I'll take a look hypfs as an immediate solution, if that's preferred.
> 
> Paul, if you'd like me to add a few patches to my series doing the basic
> framework (per-domain nodes, interfaces for setting struct domain fields
> via hypfs), I can do that. You could then concentrate on the tools side.
> 

That would be very helpful. Thanks Juergen.

  Paul