2009-04-22 19:19:19 +04:00
|
|
|
/*
|
|
|
|
* Copyright (C) International Business Machines Corp., 2005
|
|
|
|
* Author(s): Anthony Liguori <aliguori@us.ibm.com>
|
|
|
|
*
|
|
|
|
* Copyright (C) Red Hat 2007
|
|
|
|
*
|
|
|
|
* Xen Console
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; under version 2 of the License.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2009-07-17 00:47:01 +04:00
|
|
|
* with this program; if not, see <http://www.gnu.org/licenses/>.
|
2009-04-22 19:19:19 +04:00
|
|
|
*/
|
|
|
|
|
2016-01-26 21:17:06 +03:00
|
|
|
#include "qemu/osdep.h"
|
2009-04-22 19:19:19 +04:00
|
|
|
#include <sys/select.h>
|
|
|
|
#include <termios.h>
|
|
|
|
|
2016-10-22 12:52:55 +03:00
|
|
|
#include "qapi/error.h"
|
2017-01-26 17:26:44 +03:00
|
|
|
#include "chardev/char-fe.h"
|
2019-01-08 17:48:46 +03:00
|
|
|
#include "hw/xen/xen-legacy-backend.h"
|
2009-04-22 19:19:19 +04:00
|
|
|
|
2019-06-21 13:54:41 +03:00
|
|
|
#include "hw/xen/interface/io/console.h"
|
2012-06-21 15:43:59 +04:00
|
|
|
|
2009-04-22 19:19:19 +04:00
|
|
|
struct buffer {
|
|
|
|
uint8_t *data;
|
|
|
|
size_t consumed;
|
|
|
|
size_t size;
|
|
|
|
size_t capacity;
|
|
|
|
size_t max_capacity;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct XenConsole {
|
2019-01-08 17:48:46 +03:00
|
|
|
struct XenLegacyDevice xendev; /* must be first */
|
2009-04-22 19:19:19 +04:00
|
|
|
struct buffer buffer;
|
|
|
|
char console[XEN_BUFSIZE];
|
|
|
|
int ring_ref;
|
|
|
|
void *sring;
|
2016-10-22 12:52:52 +03:00
|
|
|
CharBackend chr;
|
2009-04-22 19:19:19 +04:00
|
|
|
int backlog;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void buffer_append(struct XenConsole *con)
|
|
|
|
{
|
|
|
|
struct buffer *buffer = &con->buffer;
|
|
|
|
XENCONS_RING_IDX cons, prod, size;
|
|
|
|
struct xencons_interface *intf = con->sring;
|
|
|
|
|
|
|
|
cons = intf->out_cons;
|
|
|
|
prod = intf->out_prod;
|
|
|
|
xen_mb();
|
|
|
|
|
|
|
|
size = prod - cons;
|
|
|
|
if ((size == 0) || (size > sizeof(intf->out)))
|
2018-12-14 01:37:37 +03:00
|
|
|
return;
|
2009-04-22 19:19:19 +04:00
|
|
|
|
|
|
|
if ((buffer->capacity - buffer->size) < size) {
|
2018-12-14 01:37:37 +03:00
|
|
|
buffer->capacity += (size + 1024);
|
|
|
|
buffer->data = g_realloc(buffer->data, buffer->capacity);
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
while (cons != prod)
|
2018-12-14 01:37:37 +03:00
|
|
|
buffer->data[buffer->size++] = intf->out[
|
|
|
|
MASK_XENCONS_IDX(cons++, intf->out)];
|
2009-04-22 19:19:19 +04:00
|
|
|
|
|
|
|
xen_mb();
|
|
|
|
intf->out_cons = cons;
|
2016-10-25 08:50:16 +03:00
|
|
|
xen_pv_send_notify(&con->xendev);
|
2009-04-22 19:19:19 +04:00
|
|
|
|
|
|
|
if (buffer->max_capacity &&
|
2018-12-14 01:37:37 +03:00
|
|
|
buffer->size > buffer->max_capacity) {
|
|
|
|
/* Discard the middle of the data. */
|
2009-04-22 19:19:19 +04:00
|
|
|
|
2018-12-14 01:37:37 +03:00
|
|
|
size_t over = buffer->size - buffer->max_capacity;
|
|
|
|
uint8_t *maxpos = buffer->data + buffer->max_capacity;
|
2009-04-22 19:19:19 +04:00
|
|
|
|
2018-12-14 01:37:37 +03:00
|
|
|
memmove(maxpos - over, maxpos, over);
|
|
|
|
buffer->data = g_realloc(buffer->data, buffer->max_capacity);
|
|
|
|
buffer->size = buffer->capacity = buffer->max_capacity;
|
2009-04-22 19:19:19 +04:00
|
|
|
|
2018-12-14 01:37:37 +03:00
|
|
|
if (buffer->consumed > buffer->max_capacity - over)
|
|
|
|
buffer->consumed = buffer->max_capacity - over;
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void buffer_advance(struct buffer *buffer, size_t len)
|
|
|
|
{
|
|
|
|
buffer->consumed += len;
|
|
|
|
if (buffer->consumed == buffer->size) {
|
2018-12-14 01:37:37 +03:00
|
|
|
buffer->consumed = 0;
|
|
|
|
buffer->size = 0;
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ring_free_bytes(struct XenConsole *con)
|
|
|
|
{
|
|
|
|
struct xencons_interface *intf = con->sring;
|
|
|
|
XENCONS_RING_IDX cons, prod, space;
|
|
|
|
|
|
|
|
cons = intf->in_cons;
|
|
|
|
prod = intf->in_prod;
|
|
|
|
xen_mb();
|
|
|
|
|
|
|
|
space = prod - cons;
|
|
|
|
if (space > sizeof(intf->in))
|
2018-12-14 01:37:37 +03:00
|
|
|
return 0; /* ring is screwed: ignore it */
|
2009-04-22 19:19:19 +04:00
|
|
|
|
|
|
|
return (sizeof(intf->in) - space);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int xencons_can_receive(void *opaque)
|
|
|
|
{
|
|
|
|
struct XenConsole *con = opaque;
|
|
|
|
return ring_free_bytes(con);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xencons_receive(void *opaque, const uint8_t *buf, int len)
|
|
|
|
{
|
|
|
|
struct XenConsole *con = opaque;
|
|
|
|
struct xencons_interface *intf = con->sring;
|
|
|
|
XENCONS_RING_IDX prod;
|
|
|
|
int i, max;
|
|
|
|
|
|
|
|
max = ring_free_bytes(con);
|
|
|
|
/* The can_receive() func limits this, but check again anyway */
|
|
|
|
if (max < len)
|
2018-12-14 01:37:37 +03:00
|
|
|
len = max;
|
2009-04-22 19:19:19 +04:00
|
|
|
|
|
|
|
prod = intf->in_prod;
|
|
|
|
for (i = 0; i < len; i++) {
|
2018-12-14 01:37:37 +03:00
|
|
|
intf->in[MASK_XENCONS_IDX(prod++, intf->in)] =
|
|
|
|
buf[i];
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
xen_wmb();
|
|
|
|
intf->in_prod = prod;
|
2016-10-25 08:50:16 +03:00
|
|
|
xen_pv_send_notify(&con->xendev);
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void xencons_send(struct XenConsole *con)
|
|
|
|
{
|
|
|
|
ssize_t len, size;
|
|
|
|
|
|
|
|
size = con->buffer.size - con->buffer.consumed;
|
2017-07-06 15:08:52 +03:00
|
|
|
if (qemu_chr_fe_backend_connected(&con->chr)) {
|
2016-10-22 12:52:55 +03:00
|
|
|
len = qemu_chr_fe_write(&con->chr,
|
2016-10-22 12:52:52 +03:00
|
|
|
con->buffer.data + con->buffer.consumed,
|
|
|
|
size);
|
|
|
|
} else {
|
2009-04-22 19:19:19 +04:00
|
|
|
len = size;
|
2016-10-22 12:52:52 +03:00
|
|
|
}
|
2009-04-22 19:19:19 +04:00
|
|
|
if (len < 1) {
|
2016-10-25 08:50:07 +03:00
|
|
|
if (!con->backlog) {
|
|
|
|
con->backlog = 1;
|
2016-10-25 08:50:14 +03:00
|
|
|
xen_pv_printf(&con->xendev, 1,
|
2016-10-25 08:50:07 +03:00
|
|
|
"backlog piling up, nobody listening?\n");
|
|
|
|
}
|
2009-04-22 19:19:19 +04:00
|
|
|
} else {
|
2016-10-25 08:50:07 +03:00
|
|
|
buffer_advance(&con->buffer, len);
|
|
|
|
if (con->backlog && len == size) {
|
|
|
|
con->backlog = 0;
|
2016-10-25 08:50:14 +03:00
|
|
|
xen_pv_printf(&con->xendev, 1, "backlog is gone\n");
|
2016-10-25 08:50:07 +03:00
|
|
|
}
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
2019-01-08 17:48:46 +03:00
|
|
|
static int con_init(struct XenLegacyDevice *xendev)
|
2009-04-22 19:19:19 +04:00
|
|
|
{
|
|
|
|
struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
|
2011-06-30 21:26:29 +04:00
|
|
|
char *type, *dom, label[32];
|
2011-06-24 19:59:46 +04:00
|
|
|
int ret = 0;
|
2011-06-30 21:26:29 +04:00
|
|
|
const char *output;
|
2009-04-22 19:19:19 +04:00
|
|
|
|
|
|
|
/* setup */
|
|
|
|
dom = xs_get_domain_path(xenstore, con->xendev.dom);
|
2012-12-17 15:36:09 +04:00
|
|
|
if (!xendev->dev) {
|
|
|
|
snprintf(con->console, sizeof(con->console), "%s/console", dom);
|
|
|
|
} else {
|
|
|
|
snprintf(con->console, sizeof(con->console), "%s/device/console/%d", dom, xendev->dev);
|
|
|
|
}
|
2009-04-22 19:19:19 +04:00
|
|
|
free(dom);
|
|
|
|
|
|
|
|
type = xenstore_read_str(con->console, "type");
|
2009-04-23 22:42:30 +04:00
|
|
|
if (!type || strcmp(type, "ioemu") != 0) {
|
2016-10-25 08:50:14 +03:00
|
|
|
xen_pv_printf(xendev, 1, "not for me (type=%s)\n", type);
|
2011-06-24 19:59:46 +04:00
|
|
|
ret = -1;
|
|
|
|
goto out;
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
|
2011-06-30 21:26:29 +04:00
|
|
|
output = xenstore_read_str(con->console, "output");
|
2011-07-03 11:44:48 +04:00
|
|
|
|
|
|
|
/* no Xen override, use qemu output device */
|
2011-06-30 21:26:29 +04:00
|
|
|
if (output == NULL) {
|
2016-10-22 12:52:52 +03:00
|
|
|
if (con->xendev.dev) {
|
2018-04-20 17:52:43 +03:00
|
|
|
qemu_chr_fe_init(&con->chr, serial_hd(con->xendev.dev),
|
2016-10-22 12:52:52 +03:00
|
|
|
&error_abort);
|
|
|
|
}
|
2011-07-03 11:44:48 +04:00
|
|
|
} else {
|
|
|
|
snprintf(label, sizeof(label), "xencons%d", con->xendev.dev);
|
2016-10-22 12:52:52 +03:00
|
|
|
qemu_chr_fe_init(&con->chr,
|
chardev: mark the calls that allow an implicit mux monitor
This is mostly for readability of the code. Let's make it clear which
callers can create an implicit monitor when the chardev is muxed.
This will also enforce a safer behaviour, as we don't really support
creating monitor anywhere/anytime at the moment. Add an assert() to
make sure the programmer explicitely wanted that behaviour.
There are documented cases, such as: -serial/-parallel/-virtioconsole
and to less extent -debugcon.
Less obvious and questionable ones are -gdb, SLIRP -guestfwd and Xen
console. Add a FIXME note for those, but keep the support for now.
Other qemu_chr_new() callers either have a fixed parameter/filename
string or do not need it, such as -qtest:
* qtest.c: qtest_init()
Afaik, only used by tests/libqtest.c, without mux. I don't think we
support it outside of qemu testing: drop support for implicit mux
monitor (qemu_chr_new() call: no implicit mux now).
* hw/
All with literal @filename argument that doesn't enable mux monitor.
* tests/
All with @filename argument that doesn't enable mux monitor.
On a related note, the list of monitor creation places:
- the chardev creators listed above: all from command line (except
perhaps Xen console?)
- -gdb & hmp gdbserver will create a "GDB monitor command" chardev
that is wired to an HMP monitor.
- -mon command line option
From this short study, I would like to think that a monitor may only
be created in the main thread today, though I remain skeptical :)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
2018-08-22 20:19:42 +03:00
|
|
|
/*
|
|
|
|
* FIXME: sure we want to support implicit
|
|
|
|
* muxed monitors here?
|
|
|
|
*/
|
2019-02-13 16:18:13 +03:00
|
|
|
qemu_chr_new_mux_mon(label, output, NULL),
|
|
|
|
&error_abort);
|
2011-06-30 21:26:29 +04:00
|
|
|
}
|
2011-07-03 11:44:48 +04:00
|
|
|
|
2016-10-22 12:52:55 +03:00
|
|
|
xenstore_store_pv_console_info(con->xendev.dev,
|
|
|
|
qemu_chr_fe_get_driver(&con->chr));
|
2009-04-22 19:19:19 +04:00
|
|
|
|
2011-06-24 19:59:46 +04:00
|
|
|
out:
|
2011-08-21 07:09:37 +04:00
|
|
|
g_free(type);
|
2011-06-24 19:59:46 +04:00
|
|
|
return ret;
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
|
2019-01-08 17:48:46 +03:00
|
|
|
static int con_initialise(struct XenLegacyDevice *xendev)
|
2009-04-22 19:19:19 +04:00
|
|
|
{
|
|
|
|
struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
|
|
|
|
int limit;
|
|
|
|
|
|
|
|
if (xenstore_read_int(con->console, "ring-ref", &con->ring_ref) == -1)
|
2018-12-14 01:37:37 +03:00
|
|
|
return -1;
|
2009-04-22 19:19:19 +04:00
|
|
|
if (xenstore_read_int(con->console, "port", &con->xendev.remote_port) == -1)
|
2018-12-14 01:37:37 +03:00
|
|
|
return -1;
|
2009-04-22 19:19:19 +04:00
|
|
|
if (xenstore_read_int(con->console, "limit", &limit) == 0)
|
2018-12-14 01:37:37 +03:00
|
|
|
con->buffer.max_capacity = limit;
|
2009-04-22 19:19:19 +04:00
|
|
|
|
2012-12-17 15:36:09 +04:00
|
|
|
if (!xendev->dev) {
|
2016-01-15 16:23:40 +03:00
|
|
|
xen_pfn_t mfn = con->ring_ref;
|
xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory API.
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.
One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_{pages,bulk}.
The new xenforeignmemory_map() function behaves like
xc_map_foreign_pages() when the err argument is NULL and like
xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
here onto checking err == NULL and calling the appropriate old
function.
Note that xenforeignmemory_map() takes the number of pages before the
arrays themselves, in order to support potentially future use of
variable-length-arrays in the prototype (in the future, when Xen's
baseline toolchain requirements are new enough to ensure VLAs are
supported).
In preparation for adding support for libxenforeignmemory add support
to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
switch to using the new API. These shims will disappear for versions
of Xen which include libxenforeignmemory.
Since libxenforeignmemory will have its own handle type but for <= 4.6
the functionality is provided by using a libxenctrl handle we
introduce a new global xen_fmem alongside the existing xen_xc. In fact
we make xen_fmem a pointer to the existing xen_xc, which then works
correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
is a pointer). In the latter case xen_fmem is actually a double
indirect pointer, but it all falls out in the wash.
Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
rather than just specifying that munmap should be used, so the unmap
paths are updated to use xenforeignmemory_unmap, which is a shim for
munmap on these versions of xen. The mappings in xen-hvm.c do not
appear to be unmapped (which makes sense for a qemu-dm process)
In fb_disconnect this results in a change from simply mmap over the
existing mapping (with an implicit munmap) to expliclty unmapping with
xenforeignmemory_unmap and then mapping the required anonymous memory
in the same hole. I don't think this is a problem since any other
thread which was racily touching this region would already be running
the risk of hitting the mapping halfway through the call. If this is
thought to be a problem then we could consider adding an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2016-01-15 16:23:41 +03:00
|
|
|
con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom,
|
2018-05-17 18:35:53 +03:00
|
|
|
PROT_READ | PROT_WRITE,
|
xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory API.
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.
One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_{pages,bulk}.
The new xenforeignmemory_map() function behaves like
xc_map_foreign_pages() when the err argument is NULL and like
xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
here onto checking err == NULL and calling the appropriate old
function.
Note that xenforeignmemory_map() takes the number of pages before the
arrays themselves, in order to support potentially future use of
variable-length-arrays in the prototype (in the future, when Xen's
baseline toolchain requirements are new enough to ensure VLAs are
supported).
In preparation for adding support for libxenforeignmemory add support
to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
switch to using the new API. These shims will disappear for versions
of Xen which include libxenforeignmemory.
Since libxenforeignmemory will have its own handle type but for <= 4.6
the functionality is provided by using a libxenctrl handle we
introduce a new global xen_fmem alongside the existing xen_xc. In fact
we make xen_fmem a pointer to the existing xen_xc, which then works
correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
is a pointer). In the latter case xen_fmem is actually a double
indirect pointer, but it all falls out in the wash.
Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
rather than just specifying that munmap should be used, so the unmap
paths are updated to use xenforeignmemory_unmap, which is a shim for
munmap on these versions of xen. The mappings in xen-hvm.c do not
appear to be unmapped (which makes sense for a qemu-dm process)
In fb_disconnect this results in a change from simply mmap over the
existing mapping (with an implicit munmap) to expliclty unmapping with
xenforeignmemory_unmap and then mapping the required anonymous memory
in the same hole. I don't think this is a problem since any other
thread which was racily touching this region would already be running
the risk of hitting the mapping halfway through the call. If this is
thought to be a problem then we could consider adding an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2016-01-15 16:23:41 +03:00
|
|
|
1, &mfn, NULL);
|
2012-12-17 15:36:09 +04:00
|
|
|
} else {
|
2018-05-17 18:35:53 +03:00
|
|
|
con->sring = xen_be_map_grant_ref(xendev, con->ring_ref,
|
|
|
|
PROT_READ | PROT_WRITE);
|
2012-12-17 15:36:09 +04:00
|
|
|
}
|
2009-04-22 19:19:19 +04:00
|
|
|
if (!con->sring)
|
2018-12-14 01:37:37 +03:00
|
|
|
return -1;
|
2009-04-22 19:19:19 +04:00
|
|
|
|
|
|
|
xen_be_bind_evtchn(&con->xendev);
|
2016-10-22 12:52:59 +03:00
|
|
|
qemu_chr_fe_set_handlers(&con->chr, xencons_can_receive,
|
2017-07-06 15:08:49 +03:00
|
|
|
xencons_receive, NULL, NULL, con, NULL, true);
|
2009-04-22 19:19:19 +04:00
|
|
|
|
2016-10-25 08:50:14 +03:00
|
|
|
xen_pv_printf(xendev, 1,
|
2016-10-25 08:50:08 +03:00
|
|
|
"ring mfn %d, remote port %d, local port %d, limit %zd\n",
|
2018-12-14 01:37:37 +03:00
|
|
|
con->ring_ref,
|
|
|
|
con->xendev.remote_port,
|
|
|
|
con->xendev.local_port,
|
|
|
|
con->buffer.max_capacity);
|
2009-04-22 19:19:19 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-01-08 17:48:46 +03:00
|
|
|
static void con_disconnect(struct XenLegacyDevice *xendev)
|
2009-04-22 19:19:19 +04:00
|
|
|
{
|
|
|
|
struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
|
|
|
|
|
2017-01-26 23:49:13 +03:00
|
|
|
qemu_chr_fe_deinit(&con->chr, false);
|
2016-10-25 08:50:15 +03:00
|
|
|
xen_pv_unbind_evtchn(&con->xendev);
|
2009-04-22 19:19:19 +04:00
|
|
|
|
|
|
|
if (con->sring) {
|
2016-01-15 16:23:37 +03:00
|
|
|
if (!xendev->dev) {
|
xen: Switch uses of xc_map_foreign_{pages,bulk} to use libxenforeignmemory API.
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.
One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_{pages,bulk}.
The new xenforeignmemory_map() function behaves like
xc_map_foreign_pages() when the err argument is NULL and like
xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
here onto checking err == NULL and calling the appropriate old
function.
Note that xenforeignmemory_map() takes the number of pages before the
arrays themselves, in order to support potentially future use of
variable-length-arrays in the prototype (in the future, when Xen's
baseline toolchain requirements are new enough to ensure VLAs are
supported).
In preparation for adding support for libxenforeignmemory add support
to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
switch to using the new API. These shims will disappear for versions
of Xen which include libxenforeignmemory.
Since libxenforeignmemory will have its own handle type but for <= 4.6
the functionality is provided by using a libxenctrl handle we
introduce a new global xen_fmem alongside the existing xen_xc. In fact
we make xen_fmem a pointer to the existing xen_xc, which then works
correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
is a pointer). In the latter case xen_fmem is actually a double
indirect pointer, but it all falls out in the wash.
Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
rather than just specifying that munmap should be used, so the unmap
paths are updated to use xenforeignmemory_unmap, which is a shim for
munmap on these versions of xen. The mappings in xen-hvm.c do not
appear to be unmapped (which makes sense for a qemu-dm process)
In fb_disconnect this results in a change from simply mmap over the
existing mapping (with an implicit munmap) to expliclty unmapping with
xenforeignmemory_unmap and then mapping the required anonymous memory
in the same hole. I don't think this is a problem since any other
thread which was racily touching this region would already be running
the risk of hitting the mapping halfway through the call. If this is
thought to be a problem then we could consider adding an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
2016-01-15 16:23:41 +03:00
|
|
|
xenforeignmemory_unmap(xen_fmem, con->sring, 1);
|
2012-12-17 15:36:09 +04:00
|
|
|
} else {
|
2018-05-17 18:35:53 +03:00
|
|
|
xen_be_unmap_grant_ref(xendev, con->sring);
|
2012-12-17 15:36:09 +04:00
|
|
|
}
|
2016-01-15 16:23:37 +03:00
|
|
|
con->sring = NULL;
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-08 17:48:46 +03:00
|
|
|
static void con_event(struct XenLegacyDevice *xendev)
|
2009-04-22 19:19:19 +04:00
|
|
|
{
|
|
|
|
struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
|
|
|
|
|
|
|
|
buffer_append(con);
|
|
|
|
if (con->buffer.size - con->buffer.consumed)
|
2018-12-14 01:37:37 +03:00
|
|
|
xencons_send(con);
|
2009-04-22 19:19:19 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
struct XenDevOps xen_console_ops = {
|
|
|
|
.size = sizeof(struct XenConsole),
|
2012-12-17 15:36:09 +04:00
|
|
|
.flags = DEVOPS_FLAG_IGNORE_STATE|DEVOPS_FLAG_NEED_GNTDEV,
|
2009-04-22 19:19:19 +04:00
|
|
|
.init = con_init,
|
2011-06-17 16:15:35 +04:00
|
|
|
.initialise = con_initialise,
|
2009-04-22 19:19:19 +04:00
|
|
|
.event = con_event,
|
|
|
|
.disconnect = con_disconnect,
|
|
|
|
};
|