Re: [Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control

[Juergen Gross <jgross@xxxxxxxx>]

On 07/02/18 12:16, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:08PM +0000, Joao Martins wrote:
>> Hey folks,
>>
>> Presented herewith is an attempt to implement PV backends feature control
>> as discussed in the list 
>> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html)
>>
>> Given that this a simple proposal hence I thought to include all changes
>> involved in the same patchset such that everyone see all the changes and has 
>> a
>> better estimate (but restricted to xen-devel just for the RFC purposes).
>>
>> The motivation here is to allow system administrators more fine grained
>> control of the device features being used by guest.
>>
>> The only change I made compared to the proposed discussed above was to use
>> "require" instead of "request" as the prefix because there is a feature which
> 
> require in the above context, like:
> 
> require-multi-queue-max-queues=2
> 
> Seems to imply that the guest _must_ have support for multiqueue and
> use exactly two queues.
> 
> What about using 'config' prefix?
> 
> config-multi-queue-max-queues=2
> config-feature-persistent=0
> 
>> has "request" in it. But if "request" is still preferred as a prefix I can 
>> change
>> it up.
>>
>> The scheme proposed is quite simple:
>>
>> * The directory "require" is created (inside the backend path) and within 
>> that
>> directory the features/capabilities names and values are written.
> 
> I'm quite sure I'm missing something, but what's the point in having
> this require directory in the xenstore backend path?
> 
> AFAICT you should just write this directly to the backend directory,
> and backends should be modified to check if there's a value already
> present before writing the default one.
> 
>> * Toolstack constructs a key value store of features, and user specifies 
>> those
>> through special entry names prefixed also as "require". Toolstack is 
>> stateless thus sys
>> admin has full control over what to pass to the backend. In other words it
>> doesn't look at particular feature names/values.
>>
>> * The backend will then use that for seeding its maximum feature set to the
>> frontend.
> 
> Oh, I see. So the backend picks up the suggested config from this
> directory together with it's capabilities and then produces the final
> set of features exposed to the frontend.
> 
> In order to prevent adding more logic to the backends, would it make
> sense to export the backend capabilities in /sys/ (or sysctl on BSDs)
> and do those calculations from the toolstack itself, so that the
> toolstack directly writes the features to the backend top level
> xenstore directory?

So you want the toolstack to read the /sys/ entries? How would that work
for driver domains?

Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel