> -----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
