On Tue, 11 Apr 2017, Bhupinder Thakur wrote: > Hi, > > Kindly let me know if my understanding is correct. > > Using a domctl API will allow us to keep the vUART configuration > flexible. Currently, we can operate on one ring-buf PFN and an event > channel port only for a single vUART but if we use DOMCTL interface, > then we can effectively get/set multiple event channel ports/multiple > PFNs from/to Xen in a single domctl call. > > I am not clear who will be the caller of this domctl API. Is it > xenconsoled or the toolstack? Currently, xenconsoled reads the > ring-buf PFN and event channel from the xenstore, which is populated > by the toolstack.
The caller could be either, but I think it would make sense for it to be xenconsoled to cut the middle-man (xl). > On 8 March 2017 at 23:52, Stefano Stabellini <sstabell...@kernel.org> wrote: > > On Wed, 8 Mar 2017, Jan Beulich wrote: > >> >>> On 08.03.17 at 15:45, <julien.gr...@arm.com> wrote: > >> > I was looking at the backend code and see it is using DOMCTL command. I > >> > guess it is considered that the console backend will be tied to a > >> > specific Xen version. Am I correct? > >> > >> I don't think I'm qualified to talk about the console backend > >> implementation (and possible quirks it has). Generally I'd expect > >> backends not to use domctl-s, as that would tie them to the tool > >> stack domain. > >> > >> > so maybe we can introduce new domctl command for handling vUART. This > >> > would avoid us to commit on an ABI and allow us to extend it if > >> > necessary in the future to support multiple UARTs. > >> > >> Well, without having the context of who it would be to use such a > >> domctl (and for what purpose) I don#t think I can comment here. > > > > I guess the assumption was that xenconsoled was part of the Xen tools. > > Indeed, it is part of the tools and is installed as such. > > > > I don't have an opinion on this. If introducing a new DOMCTL makes the > > code nicer in xen and xenconsoled, taking away some edges, like the > > changes to evtchn_send, then we should probably just do it. > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
