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

[Petre Ovidiu PIRCALABU <ppircalabu@xxxxxxxxxxxxxxx>]

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.

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

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

Many thanks,
Petre

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