Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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 <sstabellini@xxxxxxxxxx> wrote:
> > On Wed, 8 Mar 2017, Jan Beulich wrote:
> >> >>> On 08.03.17 at 15:45, <julien.grall@xxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel