|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 10/14 v4] xen/arm: vpl011: Modify xenconsole to support multiple consoles
On Wed, 7 Jun 2017, Bhupinder Thakur wrote:
> Hi Stefano,
>
> Thanks for your comments.
>
> >> diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
> >> index c5dd08d..db73e10 100644
> >> --- a/tools/console/daemon/io.c
> >> +++ b/tools/console/daemon/io.c
> >> @@ -90,12 +90,15 @@ struct buffer {
> >> };
> >>
> >> struct console {
> >> + char *xsname;
> >
> > How is xsname useful? It doesn't look like it is used anywhere except
> > init, right?
> Yes. I will remove it from the console structure.
>
> >
> >
> >> + char *ttyname;
> >> int master_fd;
> >> int master_pollfd_idx;
> >> int slave_fd;
> >> int log_fd;
> >> struct buffer buffer;
> >> - char *conspath;
> >> + char *xspath;
> >
> > A simple trick to make patch easier to handle is to separate out changes
> > like this one: renaming conspath to xspath causes a lot of churn, which
> > ends up all mixed up with other meaningful changes.
> >
> I thought that xspath is a more appropriate name than conspath because
> it tells that it is related to
> xenstore. I could keep it unchanged. Let me know. Else I will
> introduce this in a separate patch.
Yes, rename it but in a separate patch
> >
> >> + char *log_suffix;
> >> int ring_ref;
> >> xenevtchn_port_or_error_t local_port;
> >> xenevtchn_port_or_error_t remote_port;
> >> @@ -103,6 +106,23 @@ struct console {
> >> struct domain *d;
> >> };
> >>
> >> +struct console_data {
> >> + char *xsname;
> >> + char *ttyname;
> >> + char *log_suffix;
> >> +};
> >> +
> >> +static struct console_data console_data[] = {
> >> +
> >> + {
> >> + .xsname = "/console",
> >> + .ttyname = "tty",
> >> + .log_suffix = "",
> >> + },
> >> +};
> >> +
> >> +#define MAX_CONSOLE (sizeof(console_data)/sizeof(struct console_data))
> >> +
> >> struct domain {
> >> int domid;
> >> bool is_dead;
> >> @@ -112,11 +132,90 @@ struct domain {
> >> int xce_pollfd_idx;
> >> int event_count;
> >> long long next_period;
> >> - struct console console;
> >> + struct console console[MAX_CONSOLE];
> >> };
> >>
> >> +static void buffer_append(struct console *con, unsigned int data)
> >> {
> >> struct buffer *buffer = &con->buffer;
> >> + struct xencons_interface *intf = con->interface;
> >> + xenevtchn_port_or_error_t rxport = (xenevtchn_port_or_error_t)data;
> >> struct domain *dom = con->d;
> >> XENCONS_RING_IDX cons, prod, size;
> >> - struct xencons_interface *intf = con->interface;
> >> +
> >> + /* If incoming data is not for the current console then ignore. */
> >> + if (con->local_port != rxport)
> >> + return;
> >>
> >> cons = intf->out_cons;
> >> prod = intf->out_prod;
> >> @@ -427,6 +541,9 @@ static int console_create_tty(struct console *con)
> >> struct termios term;
> >> struct domain *dom = con->d;
> >>
> >> + if (!console_enabled(con))
> >> + return 1;
> >
> > Is this actually useful? It doesn't look like the rest code changed in
> > regards to console_create_tty.
> I think this check in not required as it would be called only if the
> console was initialized.
> I will remove the check.
OK
> >
> >
> >
> >> assert(con->slave_fd == -1);
> >> assert(con->master_fd == -1);
> >>
> >> @@ -594,15 +711,16 @@ static int console_create_ring(struct console *con)
> >>
> >> con->local_port = -1;
> >> con->remote_port = -1;
> >> - if (dom->xce_handle != NULL)
> >> - xenevtchn_close(dom->xce_handle);
> >>
> >> - /* Opening evtchn independently for each console is a bit
> >> - * wasteful, but that's how the code is structured... */
> >> - dom->xce_handle = xenevtchn_open(NULL, 0);
> >> - if (dom->xce_handle == NULL) {
> >> - err = errno;
> >> - goto out;
> >> + if (dom->xce_handle == NULL)
> >> + {
> >> + /* Opening evtchn independently for each console is a bit
> >> + * wasteful, but that's how the code is structured... */
> >> + dom->xce_handle = xenevtchn_open(NULL, 0);
> >> + if (dom->xce_handle == NULL) {
> >> + err = errno;
> >> + goto out;
> >> + }
> >
> > I think we need to do this per console actually, see below
> >
> >
> >> }
> >>
> >> rc = xenevtchn_bind_interdomain(dom->xce_handle,
> >> @@ -1092,14 +1282,13 @@ void handle_io(void)
> >> if ((now+5) > d->next_period) {
> >> d->next_period = now + RATE_LIMIT_PERIOD;
> >> if (d->event_count >= RATE_LIMIT_ALLOWANCE) {
> >> -
> >> (void)xenevtchn_unmask(d->xce_handle, con->local_port);
> >> + console_iter_void_arg1(d,
> >> console_event_unmask);
> >> }
> >> d->event_count = 0;
> >> }
> >> }
> >> @@ -1107,28 +1296,15 @@ void handle_io(void)
> >> d->next_period < next_timeout)
> >> next_timeout = d->next_period;
> >> } else if (d->xce_handle != NULL) {
> >> - if (discard_overflowed_data ||
> >> - !con->buffer.max_capacity ||
> >> - con->buffer.size <
> >> con->buffer.max_capacity) {
> >> - int evtchn_fd =
> >> xenevtchn_fd(d->xce_handle);
> >> - d->xce_pollfd_idx =
> >> set_fds(evtchn_fd,
> >> -
> >> POLLIN|POLLPRI);
> >> + if (console_iter_bool_arg1(d,
> >> buffer_available))
> >> + {
> >> + int evtchn_fd =
> >> xenevtchn_fd(d->xce_handle);
> >> + d->xce_pollfd_idx =
> >> set_fds(evtchn_fd,
> >> +
> >> POLLIN|POLLPRI);
> >> + }
> >> }
> >
> > Is there a reason why we have one xce_pollfd_idx, xce_handle,
> > next_period and event_count per domain, rather than per console?
> >
> > It is strange to set xce_pollfd_idx if at least one console of the
> > domain has enough buffer availability. Similarly, it is strange to count
> > the next_period on a per domain basis, regardless of the number of
> > consoles. It would be natural to do it at the console level.
>
> I tried to reuse the same event channel for handling multiple consoles
> since an event channel can handle multiple connections by allocating
> unique local ports. Considering that there will not be many consoles
> active at the same time, I thought it might be ok to reuse the same
> event channel.
>
> I agree that it is natural to make this per console. Let me know if I
> should make it per console.
Yes, please.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |