On (Tue) Oct 06 2009 [08:49:22], Christian Borntraeger wrote:
> Am Montag 05 Oktober 2009 16:05:35 schrieb Amit Shah:
> > On (Thu) Oct 01 2009 [12:28:30], Christian Borntraeger wrote:
> > > With the latest git kernel + your patch I sometmes get a completely
> > > frozen console. In the dump there i
Am Montag 05 Oktober 2009 16:05:35 schrieb Amit Shah:
> On (Thu) Oct 01 2009 [12:28:30], Christian Borntraeger wrote:
> > With the latest git kernel + your patch I sometmes get a completely
> > frozen console. In the dump there is
> >
> > <3>virtio_console virtio0: output:id 68 is not a head!
>
On (Thu) Oct 01 2009 [12:28:30], Christian Borntraeger wrote:
>
> With the latest git kernel + your patch I sometmes get a completely frozen
> console. In the dump there is
>
> <3>virtio_console virtio0: output:id 68 is not a head!
>
> Seems that I can reproduce it with large amounts of ou
On (Thu) Oct 01 2009 [14:04:37], Christian Borntraeger wrote:
> Am Donnerstag 01 Oktober 2009 13:58:01 schrieben Sie:
> > I spawned two ports; one doing 'find /' and the other transferring a
> > 800M file from the host to the guest, both running at the same time.
> > This is on top of the latest Li
Am Donnerstag 01 Oktober 2009 13:58:01 schrieben Sie:
> I spawned two ports; one doing 'find /' and the other transferring a
> 800M file from the host to the guest, both running at the same time.
> This is on top of the latest Linus tree + my patches. It works fine.
>
> Can you give me any additio
On (Thu) Oct 01 2009 [12:28:30], Christian Borntraeger wrote:
> Am Mittwoch 30 September 2009 19:13:21 schrieben Sie:
> > On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote:
> > > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah:
> > > > Great, thanks. However I was thinking of mo
On (Thu) Oct 01 2009 [12:28:30], Christian Borntraeger wrote:
> Am Mittwoch 30 September 2009 19:13:21 schrieben Sie:
> > On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote:
> > > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah:
> > > > Great, thanks. However I was thinking of mo
Am Mittwoch 30 September 2009 19:13:21 schrieben Sie:
> On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote:
> > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah:
> > > Great, thanks. However I was thinking of moving this init to the
> > > probe() routine instead of in the init_con
On (Thu) Oct 01 2009 [11:00:48], Christian Borntraeger wrote:
> Am Mittwoch 30 September 2009 19:13:21 schrieb Amit Shah:
> > - uses port->id instead of a static hvc_vtermno to pass on a value to
> > hvc_alloc(). Motivation explained within comments in the code.
>
> [...]
> > +* The first ar
Am Mittwoch 30 September 2009 19:13:21 schrieb Amit Shah:
> - uses port->id instead of a static hvc_vtermno to pass on a value to
> hvc_alloc(). Motivation explained within comments in the code.
[...]
> + * The first argument of hvc_alloc() is the virtual console
> + * number. hvc_allo
Am Donnerstag 01 Oktober 2009 10:47:37 schrieb Amit Shah:
> > > It would be great if you could test this.
> >
> > The basic stuff seems to work, but when I did a console resize I get:
>
> ...
>
> > One of the config->get() related changes is probably wrong.
>
> I see it. The following should fix
On (Thu) Oct 01 2009 [10:17:29], Christian Borntraeger wrote:
> Am Mittwoch 30 September 2009 19:13:21 schrieb Amit Shah:
> > On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote:
> > > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah:
> > > > Great, thanks. However I was thinking o
Am Mittwoch 30 September 2009 19:13:21 schrieb Amit Shah:
> On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote:
> > Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah:
> > > Great, thanks. However I was thinking of moving this init to the
> > > probe() routine instead of in the init
On (Tue) Sep 29 2009 [15:31:23], Christian Borntraeger wrote:
> Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah:
> > Great, thanks. However I was thinking of moving this init to the probe()
> > routine instead of in the init_conosle routine just because multiple
> > consoles can be added a
Am Dienstag 29 September 2009 15:09:50 schrieb Amit Shah:
> Great, thanks. However I was thinking of moving this init to the probe()
> routine instead of in the init_conosle routine just because multiple
> consoles can be added and we don't want to init this each time.. just
> once in probe is fine
On (Tue) Sep 29 2009 [22:41:45], Rusty Russell wrote:
> On Fri, 11 Sep 2009 11:43:06 pm Amit Shah wrote:
> > Expose multiple char devices ("ports") for simple communication
> > between the host userspace and guest.
>
> OK, I think other comments have died down, so it's time for a review. This
> w
On Fri, 11 Sep 2009 11:43:06 pm Amit Shah wrote:
> Expose multiple char devices ("ports") for simple communication
> between the host userspace and guest.
OK, I think other comments have died down, so it's time for a review. This
was the latest patch I could find.
The obvious way to do this is t
On (Tue) Sep 29 2009 [14:56:56], Christian Borntraeger wrote:
> Am Dienstag 29 September 2009 14:20:06 schrieb Amit Shah:
> > Christian tested the patch on s390 and found that the output was
> > very slow. He tracked it down to put_chars never getting init'ed
> > to the final value.
> >
> > Signed
Am Dienstag 29 September 2009 14:20:06 schrieb Amit Shah:
> Christian tested the patch on s390 and found that the output was
> very slow. He tracked it down to put_chars never getting init'ed
> to the final value.
>
> Signed-off-by: Amit Shah
Thanks. This fix is
Acked-by: Christian Borntraeger
On (Tue) Sep 29 2009 [14:03:08], Christian Borntraeger wrote:
> Am Dienstag 29 September 2009 11:24:31 schrieb Amit Shah:
> > -static void hvc_handle_input(struct virtqueue *vq)
> > +/* The operations for our console. */
> > +static struct hv_ops virtio_cons = {
> > + .get_chars = cons_get_chars,
Am Dienstag 29 September 2009 11:24:31 schrieb Amit Shah:
> -static void hvc_handle_input(struct virtqueue *vq)
> +/* The operations for our console. */
> +static struct hv_ops virtio_cons = {
> + .get_chars = cons_get_chars,
> + .put_chars = cons_put_chars,
> + .notifier_add = cons_not
Am Dienstag 29 September 2009 13:02:51 schrieb Christian Borntraeger:
> I took a dump and had a look. It looks that this message thing is indeed
> not the problem. Our early_put_chars method was marked as __init and the
> old code replaced the put_chars method quickly enough to never make a
> pr
Am Dienstag 29 September 2009 12:33:54 schrieben Sie:
> I've tested old qemu new kernel, new qemu old kernel, new qemu, new
> kernel and all the cases work fine.
The patch breaks at least s390 causing the following oops.
<0>[ cut here ]
On (Tue) Sep 29 2009 [12:09:25], Christian Borntraeger wrote:
> Am Dienstag 29 September 2009 11:24:31 schrieb Amit Shah:
> > OK; how I solved this is: a new internal message between the guest and
> > the host. If a host is a console port, the host has to indicate that by
> > passing a message to t
Am Dienstag 29 September 2009 11:24:31 schrieb Amit Shah:
> OK; how I solved this is: a new internal message between the guest and
> the host. If a host is a console port, the host has to indicate that by
> passing a message to the guest and the guest then hooks it up with hvc.
I am curious how yo
name
>
> which has "org.qemu.clipboard" as contents, so udev scripts could
> create a symlink:
>
> /dev/vcon/org.qemu.clipboard -> /dev/vcon3
Using these concepts, this is the current patch that I have. Please give
it a good review and consider for inclusion.
On (Tue) Sep 22 2009 [12:14:04], Rusty Russell wrote:
> On Sat, 12 Sep 2009 01:30:10 am Alan Cox wrote:
> > > The interface presented to guest userspace is of a simple char
> > > device, so it can be used like this:
> > >
> > > fd = open("/dev/vcon2", O_RDWR);
> > > ret = read(fd, buf, 100
On Sat, 12 Sep 2009 01:30:10 am Alan Cox wrote:
> > The interface presented to guest userspace is of a simple char
> > device, so it can be used like this:
> >
> > fd = open("/dev/vcon2", O_RDWR);
> > ret = read(fd, buf, 100);
> > ret = write(fd, string, strlen(string));
> >
> > Each
> Again, this is paravirtual serial device and I think it's entirely
> reasonable for people to hook up these ports in the guest directly to
> physical serial devices in the host.
virtio doesn't support all those features.
> I fail to see how this is at all relevant. This is a virtual
> machin
On (Fri) Sep 18 2009 [10:57:59], H. Peter Anvin wrote:
> On 09/18/2009 10:55 AM, Anthony Liguori wrote:
> >
> > I fail to see how this is at all relevant. This is a virtual machine,
> > we're presenting virtual hardware that behaves like a serial device.
> > Where web servers fit in is completel
On (Fri) Sep 18 2009 [12:55:20], Anthony Liguori wrote:
>> So you need a tiny kernel side driver to unpack it into a meaningful
>> fs, or just a user-user channel with a daemon each end and a protocol
>> over it - nothing kernel in that.
>>
>
> I think there's some confusion over what this drive
On 09/18/09 19:55, Anthony Liguori wrote:
>> So you need break, parity ... no be serious please
>
> Sure, why not?
>
> In QEMU, we have the ability to hook our devices directly to a physical
> serial device and we pass through break, parity, and the other serial
> device properties.
Yes for a emul
H. Peter Anvin wrote:
> On 09/18/2009 10:55 AM, Anthony Liguori wrote:
>
>> I fail to see how this is at all relevant. This is a virtual machine,
>> we're presenting virtual hardware that behaves like a serial device.
>> Where web servers fit in is completely beyond me.
>>
>>
>
> s/virtio
On 09/18/2009 10:55 AM, Anthony Liguori wrote:
>
> I fail to see how this is at all relevant. This is a virtual machine,
> we're presenting virtual hardware that behaves like a serial device.
> Where web servers fit in is completely beyond me.
>
s/virtio_console/virtio_serial/
There is a fair
Alan Cox wrote:
>> We do actually want hangup and a few other of the tty specific ops.
>> The only thing we really don't want is a baud rate.
>>
>
> So you need break, parity ... no be serious please
>
Sure, why not?
In QEMU, we have the ability to hook our devices directly to a physical
> We do actually want hangup and a few other of the tty specific ops.
> The only thing we really don't want is a baud rate.
So you need break, parity ... no be serious please
> This device cannot be implemented as-is in userspace because it
> depends on DMA which precludes the use of something li
On (Thu) Sep 17 2009 [16:57:01], Alan Cox wrote:
> > Alan, I'm not sure how many ports at a time people would want to use so
> > allocating one major device for this seems OK?
>
> We have very large minor number ranges now so one dynamic major should do
> you for a while yet. Probably forever but
> Alan, I'm not sure how many ports at a time people would want to use so
> allocating one major device for this seems OK?
We have very large minor number ranges now so one dynamic major should do
you for a while yet. Probably forever but thats always asking for a
"640K.." moment ;)
> +static ss
On (Thu) Sep 17 2009 [14:15:31], Alan Cox wrote:
> > Well, really fundamentally, this is just a reliable full-duplex byte
> > stream, with connect and hangup notification. To me, that sounds more
> > like TCP with an address family almost, but not quite AF_UNIX, but that
> > case was thrown out of
> Well, really fundamentally, this is just a reliable full-duplex byte
> stream, with connect and hangup notification. To me, that sounds more
> like TCP with an address family almost, but not quite AF_UNIX, but that
> case was thrown out of court long ago, so here we are.
Well the tty one has al
Anthony Liguori writes:
> Alan Cox wrote:
>>> This device is very much a serial port. I don't see any reason not
>>> to treat it like one.
>>>
>>
>> Here are a few
>>
>> - You don't need POSIX multi-open semantics, hangup and the like
>>
>
> We do actually want hangup and a few other of
Alan Cox wrote:
>> This device is very much a serial port. I don't see any reason not
>> to treat it like one.
>>
>
> Here are a few
>
> - You don't need POSIX multi-open semantics, hangup and the like
>
We do actually want hangup and a few other of the tty specific ops. The
only thing
> This device is very much a serial port. I don't see any reason not
> to treat it like one.
Here are a few
- You don't need POSIX multi-open semantics, hangup and the like
- Seek makes sense on some kinds of fixed attributes
- TTY has a relatively large memory overhead per device
- Sysfs is wha
Gerd Hoffmann wrote:
>> Userspace can detect when new virtio-consoles appear via udev events.
>> When it sees a new ttyVN, it can then look in sysfs to discover it's
>> name.
>
> No. udev can create symlinks for you, so apps don't have to dig into
> sysfs. You'll need a rule along the lines (un
On 09/15/09 14:57, Anthony Liguori wrote:
> That's probably not what we want. I imagine what we want is:
>
> /dev/ttyV0
> /dev/ttyV1
> /dev/ttyVN
Yes.
> And then we want:
>
> /sys/class/virtio-console/ttyV0/name -> "org.qemu.clipboard"
Yes.
> Userspace can detect when new virtio-consoles appear
Amit Shah wrote:
> On (Tue) Sep 15 2009 [07:57:10], Anthony Liguori wrote:
>
>> Amit Shah wrote:
>>
>>> Hey Greg,
>>>
>>> Can you tell me how this could work out -- each console port could have
>>> a "role" string associated with it (obtainable from the invoking qemu
>>> process in case of
On (Tue) Sep 15 2009 [07:57:10], Anthony Liguori wrote:
> Amit Shah wrote:
>> Hey Greg,
>>
>> Can you tell me how this could work out -- each console port could have
>> a "role" string associated with it (obtainable from the invoking qemu
>> process in case of qemu/kvm). Something that I have in mi
Amit Shah wrote:
> Hey Greg,
>
> Can you tell me how this could work out -- each console port could have
> a "role" string associated with it (obtainable from the invoking qemu
> process in case of qemu/kvm). Something that I have in mind currently
> is:
>
> $ qemu-kvm ... -virtioconsole role=org/q
[Adding Greg to the CC list]
On (Fri) Sep 11 2009 [17:00:10], Alan Cox wrote:
> > The interface presented to guest userspace is of a simple char
> > device, so it can be used like this:
> >
> > fd = open("/dev/vcon2", O_RDWR);
> > ret = read(fd, buf, 100);
> > ret = write(fd, string,
Amit Shah wrote:
> On (Fri) Sep 11 2009 [12:26:16], Anthony Liguori wrote:
>
>> Amit Shah wrote:
>>
>>> Right; there was some discussion about this. A few alternatives were
>>> suggested like
>>>
>>> - udev scripts to create symlinks from ports to function, like:
>>>
>>> /dev/vcon3 -> /de
On (Fri) Sep 11 2009 [12:26:16], Anthony Liguori wrote:
> Amit Shah wrote:
>> Right; there was some discussion about this. A few alternatives were
>> suggested like
>>
>> - udev scripts to create symlinks from ports to function, like:
>>
>> /dev/vcon3 -> /dev/virtio-console/clipboard
>>
>> - Some
Amit Shah wrote:
> Right; there was some discussion about this. A few alternatives were
> suggested like
>
> - udev scripts to create symlinks from ports to function, like:
>
> /dev/vcon3 -> /dev/virtio-console/clipboard
>
> - Some fqdn-like hierarchy, like
>
> /dev/virtio-console/com/redhat/cl
On (Fri) Sep 11 2009 [17:00:10], Alan Cox wrote:
> > The interface presented to guest userspace is of a simple char
> > device, so it can be used like this:
> >
> > fd = open("/dev/vcon2", O_RDWR);
> > ret = read(fd, buf, 100);
> > ret = write(fd, string, strlen(string));
> >
> > Each
> The interface presented to guest userspace is of a simple char
> device, so it can be used like this:
>
> fd = open("/dev/vcon2", O_RDWR);
> ret = read(fd, buf, 100);
> ret = write(fd, string, strlen(string));
>
> Each port is to be assigned a unique function, for example, the
> fir
Expose multiple char devices ("ports") for simple communication
between the host userspace and guest.
Sample offline usages can be: poking around in a guest to find out
the file systems used, applications installed, etc. Online usages
can be sharing of clipboard data between the guest and the host
Expose multiple char devices ("ports") for simple communication
between the host userspace and guest.
Sample offline usages can be: poking around in a guest to find out
the file systems used, applications installed, etc. Online usages
can be sharing of clipboard data between the guest and the host
56 matches
Mail list logo
