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
> 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 tr
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 t
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.
>
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.
>
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 atom
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, i
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 natural to extend
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 atom
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 t
On Tue, 10 Nov 2009 08:11:27 pm Amit Shah wrote:
> 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.
(I've decid
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 stru
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
> ---
> drivers/vhost/
This is helpful in examining ports' state.
Signed-off-by: Amit Shah
---
drivers/char/virtio_console.c | 64 -
1 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8c9bac8..f7d
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
---
drivers/char/virtio_console.c | 49
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
---
drivers/char/virtio_console.c | 102 +++-
include
Remove port data; deregister from the hvc core if it's a console port.
Signed-off-by: Amit Shah
---
drivers/char/virtio_console.c | 64
include/linux/virtio_console.h |2 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/drivers/cha
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 stores
Add a guest_connected field that ensures only one process
can have a port open at a time.
Signed-off-by: Amit Shah
---
drivers/char/virtio_console.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_conso
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
---
drivers/char/virtio_console.c | 41 +
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
---
drivers/char/virtio_console.c | 53 ++
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
---
drivers/char/virtio_console.c |8 +++-
1 files
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 console could be flooded with data from the host; handle
this situation by buffering the data.
Signed-off-by: Amit Shah
---
drivers/char/virtio_console.c | 210 +
1 files changed, 149 insertions(+), 61 deletions(-)
diff --git a/drivers/char/virtio_co
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 alloca
Club all the globals -- the virtio_device struct, virtqueues,
hvc_console struct, inbuf, len, etc. into one virtioconsole
struct.
Signed-off-by: Amit Shah
---
drivers/char/virtio_console.c | 83 -
1 files changed, 49 insertions(+), 34 deletions(-)
diff
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
---
drivers/char/virtio_console.c | 50
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
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
---
drivers/char/virtio_console.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char
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 por
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
> To: Christian Borntraeger
> Cc: linuxppc-...@ozlabs.org
> ---
> drivers/char/hvc_beat.c
31 matches
Mail list logo