Re: [RFC PATCH 4/6] vm_event: Use slotted channels for sync requests.

From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Razvan Cojocaru' <rcojocaru@bitdefender.com>,
	'Petre Ovidiu PIRCALABU' <ppircalabu@bitdefender.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Tamas K Lengyel <tamas@tklengyel.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	George Dunlap <George.Dunlap@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [RFC PATCH 4/6] vm_event: Use slotted channels for sync requests.
Date: Thu, 10 Jan 2019 09:58:21 +0000	[thread overview]
Message-ID: <0ed3844a200940e18da621d7064aa251@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <11b37040-047b-7d67-8d41-81ec3fd35a87@bitdefender.com>

> -----Original Message-----

> >>>
> >>> Why re-invent the wheel here? The ioreq infrastructure already does
> >>> pretty much everything you need AFAICT.
> >>>
> >>>    Paul
> >>
> >> I wanted preseve as much as possible from the existing vm_event DOMCTL
> >> interface and add only the necessary code to allocate and map the
> >> vm_event_pages.
> >
> > That means we have two subsystems duplicating a lot of functionality
> though. It would be much better to use ioreq server if possible than
> provide a compatibility interface via DOMCTL.
> 
> Just to clarify the compatibility issue: there's a third element between
> Xen and the introspection application, the Linux kernel which needs to
> be fairly recent for the whole ioreq machinery to work. The qemu code
> also seems to fallback to the old way of working if that's the case.
> 

Tht'a corrent. For IOREQ server there is a fall-back mechanism when privcmd doesn't support resource mapping.

> This means that there's a choice to be made here: either we keep
> backwards compatibility with the old vm_event interface (in which case
> we can't drop the waitqueue code), or we switch to the new one and leave
> older setups in the dust (but there's less code duplication and we can
> get rid of the waitqueue code).
> 

I don't know what your compatibility model is. QEMU needs to maintain compatibility across various different versions of Xen and Linux so there are many shims and much compat code. You may not need this.

> In any event, it's not very clear (to me, at least) how the envisioned
> ioreq replacement should work. I assume we're meant to use the whole
> infrastructure (as opposed to what we're now doing, which is to only use
> the map-hypervisor-memory part), i.e. both mapping and signaling. Could
> we discuss this in more detail? Are there any docs on this or ioreq
> minimal clients (like xen-access.c is for vm_event) we might use?
> 

I don't know how much of the infrastructure will be re-usable for you. Resource mapping itself is supposed to be generic, not specific to IOREQ server. Indeed it already supports grant table mapping too. So IMO you should at least expose your shared pages using this mechanism.

It would be nice if you could also re-use ioreqs (and bufioreqs) for sending your data but they may well be a poor fit... but you could probably cut'n'paste some of the init and teardown code to set up your shared pages.

  Paul

> 
> Thanks,
> Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel