Am Dienstag 10 November 2009 07:27:30 schrieb Rusty Russell:
This is nicer for modern R/O protection. And noone needs it non-const, so
constify the callers as well.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
To: Christian Borntraeger borntrae...@de.ibm.com
Cc:
On (Tue) Nov 10 2009 [16:57:30], Rusty Russell wrote:
Rather than assume a single port, add a 'struct ports' with an array
of ports. Currently, there's always only one, but that will change.
Hey Rusty,
static void virtcons_apply_config(struct virtio_device *dev)
{
- struct port
We support only one virtio_console device at a time. If multiple are
found, error out if one is already initialized.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
Hey Rusty,
This is the way I did the split; patches 1..7 are preparation for
multiple ports.
Patch 8 adds multiport support. It's the big one since we have to put
the header in and retain support for multiple consoles and console
resizing.
Patch 9 adds port hotplug
Patch 10 adds sysfs entries
Club all the globals -- the virtio_device struct, virtqueues,
hvc_console struct, inbuf, len, etc. into one virtioconsole
struct.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c | 83 -
1 files changed, 49 insertions(+),
Initialize the hv_ops function pointers using C99 style. However, we
need to re-init the 'put_chars' field to our implementation in the
probe() routine as we replace it for early_init to use the caller's
put_chars implementation.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
We currently only maintain one buffer for any data the host sends
us. If we're slow in consuming that data, we might lose old data.
To buffer the data that the host sends us, we need to be able to
allocate buffers as and when the host sends us some.
Using a workqueue gives us the freedom to
The console could be flooded with data from the host; handle
this situation by buffering the data.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c | 210 +
1 files changed, 149 insertions(+), 61 deletions(-)
diff --git
The current implementation used to write data to the host
and then wait till the host consumed it.
Also, there was no support to send large chunks of data.
This patch adds support to send big chunks in multiple
buffers of PAGE_SIZE each to the host. It also 'sends
and forgets' the data it sent.
The config_changed function works on the assumption of there
being only one port and no hotplugging of ports.
Abstract away the call to apply_config in a function call so
that we can handle multiple ports later.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c |
If the 'nr_ports' variable in the config space is updated to
a higher value, that means new ports have been hotplugged.
Introduce a new workqueue to handle such updates and create
new ports.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c | 53
A name property, if set by the host, is exposed in
/sys/class/virtio-console/vconNN/name
that can be used to create symlinks by udev scripts, example:
/dev/vcon/org.libvirt.channel.0 - /dev/vcon1
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c | 41
Add a guest_connected field that ensures only one process
can have a port open at a time.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/char/virtio_console.c
Add a bit more spice by adding support for multiple console ports.
This introduces a new feature: VIRTIO_CONSOLE_F_MULTIPORT. If a
willing host is found, this support is switched on and a small
'header' is transmitted along with every data packet that's sent
in either direction.
This header
Remove port data; deregister from the hvc core if it's a console port.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c | 64
include/linux/virtio_console.h |2 +
2 files changed, 66 insertions(+), 0 deletions(-)
Rogue processes on guests or hosts could pump in data
and cause an OOM condition. Add support for throttling
so that a limit to the number of outstanding buffers
can be specified.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/virtio_console.c | 102
If caching of buffers upon closing a port is not desired,
delete all the buffers queued up for the port upon port
close.
This only applies to generic ports; console ports aren't
opened / closed by the chardev interface.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
On Tue, Nov 10, 2009 at 01:49:09PM +1030, Rusty Russell wrote:
One fix:
vhost: fix TUN=m VHOST_NET=y
drivers/built-in.o: In function `get_tun_socket':
net.c:(.text+0x15436e): undefined reference to `tun_get_socket'
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
On Tue, 10 Nov 2009 08:03:28 pm Amit Shah wrote:
On (Tue) Nov 10 2009 [16:57:30], Rusty Russell wrote:
Rather than assume a single port, add a 'struct ports' with an array
of ports. Currently, there's always only one, but that will change.
Hey Rusty,
Hi Amit,
-static struct port
On Tue, 10 Nov 2009 05:54:14 pm Amit Shah wrote:
2) Do we really need more than input buffer at a time? If not, it's easy to
generalize the input callback. This will be slow, but shouldn't be a
problem.
In my testing of a vnc clipboard copy/paste, the vnc client only sent the
Rusty Russell wrote:
On Tue, 10 Nov 2009 03:02:06 am Adam Litke wrote:
A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them to the host via the device config space.
There are two issues I see with this. First, there's an atomicity
Avi Kivity wrote:
On 11/10/2009 04:36 PM, Anthony Liguori wrote:
A stats vq might solve this more cleanly?
actual and target are both really just stats. Had we implemented
those with a vq, I'd be inclined to agree with you but since they're
implemented in the config space, it seems
Rusty Russell wrote:
On Tue, 10 Nov 2009 03:02:06 am Adam Litke wrote:
A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them to the host via the device config space.
There are two issues I see with this. First, there's an atomicity
On Wed, 11 Nov 2009 01:06:14 am Anthony Liguori wrote:
Rusty Russell wrote:
On Tue, 10 Nov 2009 03:02:06 am Adam Litke wrote:
A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them to the host via the device config
space.
On Wed, 11 Nov 2009 08:22:42 am Anthony Liguori wrote:
Rusty Russell wrote:
On Tue, 10 Nov 2009 03:02:06 am Adam Litke wrote:
A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them to the host via the device config
space.
Rusty Russell wrote:
On Wed, 11 Nov 2009 08:22:42 am Anthony Liguori wrote:
Rusty Russell wrote:
On Tue, 10 Nov 2009 03:02:06 am Adam Litke wrote:
A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them to the host via the
But I certainly do _not_ want to update the SCSI disk
emulation, as this is really quite tied to the SCSI parallel
interface used by the old lsi53c895a.c.
This is completely untrue. scsi-disk.c contains no transport-specific code. It
is deliberately designed to be independent of both the
On Wed, 11 Nov 2009 10:37:56 am Anthony Liguori wrote:
Rusty Russell wrote:
You register an outbuf at initialization time. The host hands it back when
it wants you to refill it with stats.
That's strangely backwards. Guest send a stat buffer that's filled out,
host acks it when it
28 matches
Mail list logo
