Re: [Xen-devel] [RFC PATCH 6/6] xc_version: add vm_event interface version

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.02.19 at 17:57, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
> On Wed, 2019-01-09 at 11:11 +0200, Razvan Cojocaru wrote:
>> 
>> On 1/8/19 6:47 PM, Jan Beulich wrote:
>> > > > > On 08.01.19 at 17:37, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> > > 
>> > > On 1/8/19 6:27 PM, Jan Beulich wrote:
>> > > > > > > On 19.12.18 at 19:52, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
>> > > > > 
>> > > > > Signed-off-by: Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>
>> > > > 
>> > > > An empty description is not helpful. The immediate question is:
>> > > > Why?
>> > > > We don't do this for other interface versions. I'm unconvinced
>> > > > a
>> > > > special purpose piece of information like this one belongs into
>> > > > the
>> > > > rather generic version hypercall.
>> > > 
>> > > For an introspection application meant to be deployed on several
>> > > Xen
>> > > versions without recompiling, it is important to be able to
>> > > decide at
>> > > runtime what size and layout the vm_event struct has.
>> > > 
>> > > Currently this can somewhat be done by associating the current
>> > > version
>> > > with the vm_event version, but that is not ideal for obvious
>> > > reasons.
>> > > Reading the vm_event version from an actual vm_event is also out
>> > > of the
>> > > question, because in order to be able to receive the first
>> > > vm_event we
>> > > have to set the ring buffer up, and that requires knowledge of
>> > > the size
>> > > of the vm_event. So a run-time mechanism for querying the
>> > > vm_event
>> > > version is needed.
>> > > 
>> > > We just thought that this was the most flexible place to add it.
>> > 
>> > How about a new XEN_DOMCTL_VM_EVENT_GET_VERSION?
>> 
>> That would work as well, we just thought this was the least
>> intrusive 
>> and most extensible way to do it (other queries could be added
>> similarly 
>> in the future, without needing a new DOMCTL / libxc toolstack 
>> modifications).
>> 
> Personally, would prefer the xc_version approach because it has a
> number of advantages over a creating specific domctl:
> 
> - First, it's a version. In my opinion, if an interface too strongly
> coupled with XEN that it cannot be disabled at configure-time, it's
> generic enough to be queried by the common version functions. An 
> example of getting specialized information from XEN is
> XENVER_get_features, which is also handled using xc_version.

Whether XENVER_get_features is a good fit there is questionable,
but it's been there for too long to be (re)moved.

> - This interface version is hypervisor specific. A client application
> should be able to query this version at startup, even before the
> monitor domain is available, and a domctl requires a domain id. The
> DOM0 id or DOMID_INVALID can be used, but I find it rather confusing to
> query something hypervisor specific and pass a domain related param.

Well, I did suggest a domctl because there already is
XEN_DOMCTL_vm_event_op, and it could be a sub-op there.
Of course you could also add a sysctl just for this, or a whole
new major hypercall ...

Note how XEN_DOMCTL_createdomain (obviously) also can't
possibly be handed a domain ID.

> - It's simple and it can be easily extended.

As are any other (simple) hypercalls.

As you can see I continue to be opposed to add special
purpose subsystem information to a general hypercall (of
whatever sort). However, as so often I'm not opposed
enough to actively nack such an addition, so if other REST
maintainers think this is an appropriate thing to do, so be it.

Jan



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