Avi Kivity wrote:
On 04/12/2010 01:58 PM, Yoshiaki Tamura wrote:
Is it necessary to update migration and vga bitmaps?
We can simply update the master bitmap, and update the migration and vga
bitmaps only when they need it. That can be done in a different patch.
Let me explain the role of the
2010/4/12 Gerhard Wiesinger :
> Hello,
>
> Checkit reports some problems under DOS:
> 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED.
> Seems to be a problem of the instruction set.
> 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the
> KVM problem, see
Please send in any agenda items you are interested in covering.
thanks,
-chris
Hi,
> So for the already-translated code, we will miss singlestep?
At least SH4(and mips?) shows such behaviour.
I think a patch below enables single stepping in such case, too.
But, I'm not sure if this behaviour is on purpose, nor this patch is correct.
/yoshii
diff --git a/target-sh4/translate.
From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001
From: Izik Eidus
Date: Tue, 13 Apr 2010 12:24:57 +0300
Subject: [PATCH] fix migration with large mem
In cases of guests with large mem that have pages
that all their bytes content are the same, we will
spend alot of time readi
Signed-off-by: Stefan Hajnoczi
---
block.c | 22 --
block_int.h |2 +-
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/block.c b/block.c
index 5d087de..12cf434 100644
--- a/block.c
+++ b/block.c
@@ -58,7 +58,8 @@ static int bdrv_write_em(BlockDriverS
Several commands have code to create a BlockDriverState and open a file.
The bdrv_new_open() function can be used to perform these steps. This
patch converts the qemu-img commands to actually use bdrv_new_open().
Replaced the bdrv_new_open() 'readonly' argument with bdrv_open()-style
flags to sup
It should be BDRV_O_FLAGS instead of BRDV_O_FLAGS.
Signed-off-by: Stefan Hajnoczi
---
qemu-img.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index b30effa..7203b8b 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -37,7 +37,7 @@
These patches apply to Kevin's block branch.
On Tue, Apr 13, 2010 at 6:21 PM, wrote:
> Hi,
>> So for the already-translated code, we will miss singlestep?
> At least SH4(and mips?) shows such behaviour.
> I think a patch below enables single stepping in such case, too.
> But, I'm not sure if this behaviour is on purpose, nor this patch is c
On 04/13/2010 11:01 AM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 04/12/2010 01:58 PM, Yoshiaki Tamura wrote:
Is it necessary to update migration and vga bitmaps?
We can simply update the master bitmap, and update the migration
and vga
bitmaps only when they need it. That can be done in a
The bdrv_create2 implementation has been disappeared long ago. Remove its
prototype from the header file, too.
Signed-off-by: Kevin Wolf
---
block.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/block.h b/block.h
index 4a57dd5..05ad572 100644
--- a/block.h
+++ b/blo
Avi Kivity wrote:
On 04/13/2010 11:01 AM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 04/12/2010 01:58 PM, Yoshiaki Tamura wrote:
Is it necessary to update migration and vga bitmaps?
We can simply update the master bitmap, and update the migration
and vga
bitmaps only when they need it. That
Am 13.04.2010 11:29, schrieb Stefan Hajnoczi:
> These patches apply to Kevin's block branch.
Thanks. Looks good, applied all to the block branch.
Kevin
Paul Brook wrote:
>> A major reason for this deadlock could likely be removed by shutting
>> down the tap (if peered) or dropping packets in user space (in case of
>> vlan) when a NIC is stopped or otherwise shut down. Currently most (if
>> not all) NIC models seem to signal both "queue full" and "
Jamie Lokier wrote:
> Paul Brook wrote:
>>> A major reason for this deadlock could likely be removed by shutting
>>> down the tap (if peered) or dropping packets in user space (in case of
>>> vlan) when a NIC is stopped or otherwise shut down. Currently most (if
>>> not all) NIC models seem to sign
Paul Brook wrote:
>> But anyway, this flow control mechanism is buggy - what if instead of
>> an interface down, you just have a *slow* guest? That should not push
>> back so much that it makes other guests networking with each other
>> slow down.
>
> The OP described multiple guests connected vi
Ensure that pending requests of an SCSI disk are purged on system reset
and also restore max_lba. The latter is now only present in the reset
handler as that one is already automatically called during init.
Signed-off-by: Jan Kiszka
---
hw/scsi-disk.c | 32
1 f
> Paul Brook wrote:
> >> But anyway, this flow control mechanism is buggy - what if instead of
> >> an interface down, you just have a *slow* guest? That should not push
> >> back so much that it makes other guests networking with each other
> >> slow down.
> >
> > The OP described multiple guests
Paul Brook wrote:
>> Paul Brook wrote:
A major reason for this deadlock could likely be removed by shutting
down the tap (if peered) or dropping packets in user space (in case of
vlan) when a NIC is stopped or otherwise shut down. Currently most (if
not all) NIC models seem to s
Jun Koi wrote:
> Hi,
>
> I am looking into the singlestep command in monitor interface, and it
> seems that we only take into account the singlestep flag when we are
> translating code.
> So for the already-translated code, we will miss singlestep?
This feature is broken. For TCG, it should at le
> Paul Brook wrote:
> >> A major reason for this deadlock could likely be removed by shutting
> >> down the tap (if peered) or dropping packets in user space (in case of
> >> vlan) when a NIC is stopped or otherwise shut down. Currently most (if
> >> not all) NIC models seem to signal both "queue f
No topics, short call
On 13.04.2010, at 15:36, Jan Kiszka wrote:
> Jun Koi wrote:
>> Hi,
>>
>> I am looking into the singlestep command in monitor interface, and it
>> seems that we only take into account the singlestep flag when we are
>> translating code.
>> So for the already-translated code, we will miss singlest
Paul Brook wrote:
>> Paul Brook wrote:
>> So now everything that looks like a stream of bytes has to use the
>> virtio-serial code...
>
> IMO, yes. That's the whole point of virtio-serial.
>
> You can handle it however you like in your in your favourite guest OS, but I
> object to qemu having m
> Bear in mind that its rather unfair to (as has been in this case) have a
> patch reviewed, modified based on criticism, and then rejected after
> effort has been wasted working on it.
I'm pretty sure I raised all these issues the first time this code was
submitted.
Paul
The following situation was observed in the field:
tap1 sends packets, tap2 does not consume them, as a result
tap1 can not be closed. This happens because
tun/tap devices can hang on to skbs undefinitely.
As noted by Herbert, possible solutions include a timeout followed by a
copy/change of owner
On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote:
> The following situation was observed in the field:
> tap1 sends packets, tap2 does not consume them, as a result
> tap1 can not be closed. This happens because
> tun/tap devices can hang on to skbs undefinitely.
>
> As noted by
Alexander Graf wrote:
> On 13.04.2010, at 15:36, Jan Kiszka wrote:
>
>> Jun Koi wrote:
>>> Hi,
>>>
>>> I am looking into the singlestep command in monitor interface, and it
>>> seems that we only take into account the singlestep flag when we are
>>> translating code.
>>> So for the already-transla
> So, rather than bike-shedding, how about making some kind of decision?
Ok, let me make this simple.
Features such as rate limiting and EGD protocol translation should not be part
of individual device emulation. They are part of the host interface, not the
guest machine. If you really want th
Michael S. Tsirkin wrote:
> The following situation was observed in the field:
> tap1 sends packets, tap2 does not consume them, as a result
> tap1 can not be closed.
And before that, tap1 may not be able to send further packets to anyone
else on the bridge as its TX resources were blocked by tap2
Mulyadi Santosa wrote:
> Hi Jamie...
>
> On Mon, Apr 12, 2010 at 19:07, Jamie Lokier wrote:
>> There are various -no-kvm-XXX options to try:
>>
>> -no-kvm-irqchip disable KVM kernel mode PIC/IOAPIC/LAPIC
>> -no-kvm-pit disable KVM kernel mode PIT
>> -no-kvm-pit-reinjection disable KVM kernel
Eric Dumazet wrote:
> Le mardi 13 avril 2010 à 17:36 +0200, Jan Kiszka a écrit :
>> Michael S. Tsirkin wrote:
>>> The following situation was observed in the field:
>>> tap1 sends packets, tap2 does not consume them, as a result
>>> tap1 can not be closed.
>> And before that, tap1 may not be able t
On Tue, Apr 13, 2010 at 06:40:38PM +0200, Eric Dumazet wrote:
> Le mardi 13 avril 2010 à 17:36 +0200, Jan Kiszka a écrit :
> > Michael S. Tsirkin wrote:
> > > The following situation was observed in the field:
> > > tap1 sends packets, tap2 does not consume them, as a result
> > > tap1 can not be c
On Mon, Apr 12, 2010 at 04:49:16PM +0200, Kevin Wolf wrote:
> bdrv_open contains quite some code that is only useful for opening images (as
> opposed to opening files by a protocol), for example snapshots.
>
> This patch splits the code so that we have bdrv_open_file() for files (uses
> protocols)
On 4/12/10, Paul Brook wrote:
> > A major reason for this deadlock could likely be removed by shutting
> > down the tap (if peered) or dropping packets in user space (in case of
> > vlan) when a NIC is stopped or otherwise shut down. Currently most (if
> > not all) NIC models seem to signal bot
Gleb Natapov writes:
> On Sun, Feb 28, 2010 at 02:39:04PM -0500, Kevin O'Connor wrote:
>> On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote:
>>
>> > I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the
>> > image boots up fine.
>>
>> Gleb, have you seen this thread?
>>
jvrao wrote:
> Alexander Graf wrote:
>> On 12.04.2010, at 13:58, Jamie Lokier wrote:
>>
>>> Mohammed Gamal wrote:
On Mon, Apr 12, 2010 at 12:29 AM, Jamie Lokier wrote:
> Javier Guerra Giraldez wrote:
>> On Sat, Apr 10, 2010 at 7:42 AM, Mohammed Gamal
>> wrote:
>>> On Sat, Ap
On 4/13/10, Blue Swirl wrote:
> On 4/12/10, Paul Brook wrote:
> > > A major reason for this deadlock could likely be removed by shutting
> > > down the tap (if peered) or dropping packets in user space (in case of
> > > vlan) when a NIC is stopped or otherwise shut down. Currently most (if
>
On Tue, 13 Apr 2010, Roy Tam wrote:
2010/4/13 Gerhard Wiesinger :
Hello,
I'm having a problem with a DOS application which uses a 286 DOS Extender,
error message is as the following:
unable to create task for execution
Interrupt 10 (Ah) while creating task: Invalid task segment selector.
Happe
On Mon, 12 Apr 2010, Jamie Lokier wrote:
Mulyadi Santosa wrote:
Hi Gerhard...
On Sun, Apr 11, 2010 at 20:52, Gerhard Wiesinger wrote:
OK, uses the following ports:
Port 0x20: 8259 interrupt controller
Port 0x40: 8253 timer
Interrupt 0x1A:
ah=0x00: fetches system timer counters
ah=0x02: read
On Tue, Apr 13, 2010 at 9:08 PM, jvrao wrote:
> jvrao wrote:
>> Alexander Graf wrote:
>>> On 12.04.2010, at 13:58, Jamie Lokier wrote:
>>>
Mohammed Gamal wrote:
> On Mon, Apr 12, 2010 at 12:29 AM, Jamie Lokier
> wrote:
>> Javier Guerra Giraldez wrote:
>>> On Sat, Apr 10, 201
On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
> Le mardi 13 avril 2010 à 20:39 +0300, Michael S. Tsirkin a écrit :
>
> > > When a socket with inflight tx packets is closed, we dont block the
> > > close, we only delay the socket freeing once all packets were delivered
> > > and fre
On Tue, Apr 13, 2010 at 10:38:06PM +0200, Eric Dumazet wrote:
> Le mardi 13 avril 2010 à 23:25 +0300, Michael S. Tsirkin a écrit :
> > On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
> > > Le mardi 13 avril 2010 à 20:39 +0300, Michael S. Tsirkin a écrit :
> > >
> > > > > When a socke
When specifying ide devices using -device, the cmos information
which the bios depends on is not written. This patch generalizes
the cmos hd data setting for the existing code path and adds the
ability to call that code on a per machine, per ide drive basis.
This is important for older guests
Le mardi 13 avril 2010 à 17:36 +0200, Jan Kiszka a écrit :
> Michael S. Tsirkin wrote:
> > The following situation was observed in the field:
> > tap1 sends packets, tap2 does not consume them, as a result
> > tap1 can not be closed.
>
> And before that, tap1 may not be able to send further packet
Le mardi 13 avril 2010 à 20:39 +0300, Michael S. Tsirkin a écrit :
> > When a socket with inflight tx packets is closed, we dont block the
> > close, we only delay the socket freeing once all packets were delivered
> > and freed.
> >
>
> Which is wrong, since this is under userspace control, so
Le mardi 13 avril 2010 à 23:25 +0300, Michael S. Tsirkin a écrit :
> On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
> > Le mardi 13 avril 2010 à 20:39 +0300, Michael S. Tsirkin a écrit :
> >
> > > > When a socket with inflight tx packets is closed, we dont block the
> > > > close, w
On Tue, Apr 13, 2010 at 12:43:40PM +0200, Kevin Wolf wrote:
> The bdrv_create2 implementation has been disappeared long ago. Remove its
> prototype from the header file, too.
>
> Signed-off-by: Kevin Wolf
Looks good.
On Wed, Mar 31, 2010 at 09:20:31PM +0300, Michael S. Tsirkin wrote:
> From: David L Stevens
>
> vhost driver in qemu didn't ack features, and this happens
> to work because we don't really require any features. However,
> it's better not to rely on this. This patch passes features to
> vhost as g
On Thu, Apr 08, 2010 at 11:48:56PM +0300, Michael S. Tsirkin wrote:
> On Thu, Apr 08, 2010 at 05:49:50PM -0300, Marcelo Tosatti wrote:
> >
> > So the userspace headers define KERNEL_STRICT_NAMES and there's no
> > conflict on type definition for older kernels.
> >
> > igned-off-by: Marcelo Tosatt
On Mon, Apr 12, 2010 at 10:47:55AM +0200, Paolo Bonzini wrote:
> On 04/08/2010 08:37 PM, Aurelien Jarno wrote:
> >Hi all,
> >
> >A number of fixes have been accumulated in the stable-0.12 branch, and
> >I think it's time to release a new stable version. I would like to see
> >that happening for the
On Sun, Apr 04, 2010 at 05:36:55PM +0300, Michael S. Tsirkin wrote:
> vhost in current kernels doesn't support mergeable buffers.
> Disable this feature if vhost is enabled, until such
> support is implemented.
>
> Signed-off-by: Michael S. Tsirkin
Thanks, applied.
> ---
> hw/vhost_net.c |
On Fri, Apr 09, 2010 at 10:49:50PM +0200, Stefan Weil wrote:
> When argument checking is enabled, gcc throws this error:
>
> error: format not a string literal and no format arguments
>
> The patch rewrites the statement to satisfy the compiler.
>
> Signed-off-by: Stefan Weil
Thanks, applied.
On Fri, Apr 09, 2010 at 10:49:51PM +0200, Stefan Weil wrote:
> When argument checking is enabled, gcc throws this error:
>
> error: format not a string literal and no format arguments
>
> The patch rewrites the statement to satisfy the compiler.
> It also removes a type cast which is not needed.
On Fri, Apr 09, 2010 at 10:49:52PM +0200, Stefan Weil wrote:
> When argument checking is enabled, gcc throws this error:
>
> error: format not a string literal and no format arguments
>
> The patch rewrites the statement to satisfy the compiler.
>
> Signed-off-by: Stefan Weil
Thanks, applied.
On Fri, Apr 09, 2010 at 10:49:53PM +0200, Stefan Weil wrote:
> When argument checking is enabled, gcc throws this error:
>
> error: format not a string literal and no format arguments
>
> The patch rewrites the statement to satisfy the compiler.
>
> Signed-off-by: Stefan Weil
Thanks, applied.
On Sun, Apr 11, 2010 at 02:09:57AM +0900, takas...@ops.dti.ne.jp wrote:
> 2nd arg of page_set_flags() should be start+size, but size.
>
> Signed-off-by: Takashi YOSHII
Thanks, applied.
> ---
> linux-user/syscall.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/
Hi,
I have Ubuntu on my host system and I am using following command on it, to
load kernel..
*qemu -kernel kernelimage -initrd initrd.img /dev/zero -append "cmdline" *
Was wondering, how can I share/copy files from host Ubuntu system to the one
with above command?
Someone mentioned using sshfs,
Gerhard Wiesinger wrote:
> It is a non public, proprietary application which uses the Ergo Computing
> 286 DOS Extender. I guess some other application which use the same DOS
> extender have the same problem. So best thing is to find another
> application which uses the Ergo Computing 286 DOS Ex
David S. Ahern wrote:
> After a month of code refactoring and clean ups, etc, I thought I would
> send along an update. The attached patch is relative to your ehci
> branch; I also attached the full usb-ehci.c file for easier reading.
Thanks for your work! I applied it and once again merged git he
On 04/13/2010 05:35 PM, Jan Kiszka wrote:
> David S. Ahern wrote:
>> After a month of code refactoring and clean ups, etc, I thought I would
>> send along an update. The attached patch is relative to your ehci
>> branch; I also attached the full usb-ehci.c file for easier reading.
>
> Thanks for
On Tue, Apr 13, 2010 at 08:31:03PM +0200, Eric Dumazet wrote:
>
> Herbert Acked your patch, so I guess its OK, but I think it can be
> dangerous.
The tun socket accounting was never designed to stop it from
flooding another tun interface. It's there to stop it from
transmitting above a destinatio
On Tue, Apr 13, 2010 at 02:26:10PM +0800, Roy Tam wrote:
> 2010/4/12 Gerhard Wiesinger :
> > 3.) There is also a problem with the reported base memory under QEMM386
> > (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
> > Therefore base memory test fails. I guess that repor
On 14.04.2010, at 01:50, David S. Ahern wrote:
>
>
> On 04/13/2010 05:35 PM, Jan Kiszka wrote:
>> David S. Ahern wrote:
>>> After a month of code refactoring and clean ups, etc, I thought I would
>>> send along an update. The attached patch is relative to your ehci
>>> branch; I also attached t
On Tue, Apr 13, 2010 at 08:48:35PM +0200, Bjørn Mork wrote:
> Gleb Natapov writes:
> > On Sun, Feb 28, 2010 at 02:39:04PM -0500, Kevin O'Connor wrote:
> >> On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote:
> >> > I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the
> >
On 04/11/2010 03:29 PM, Michael S. Tsirkin wrote:
The following changes since commit f7e2aca83419dde3c94fa1d5e615581bb4ded9c0:
tcg/ppc: Fix typo (2010-04-06 03:10:03 +0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git for_anthony
On 04/13/2010 07:20 PM, Alexander Graf wrote:
It still needs a lot of love, but definitely an improvement from the
last version. The biggest difference for the performance boost and
stability is discovering that the usbfs in linux limits transactions to
16k versus the EHCI spe
Hello,
These patches rework the way ports are announced to the guests. A
control message is used to let the guest know a new port is
added. Initial port discovery and port hot-plug work via this way now.
This was done to have the host and guest port numbering in sync to
avoid surprises after seve
The target could be started with max_nr_ports for a virtio-serial device
lesser than what was available on the source machine. Fail the migration
in such a case.
Signed-off-by: Amit Shah
Reported-by: Juan Quintela
---
hw/virtio-serial-bus.c | 13 +++--
1 files changed, 11 insertions(+
The number of ports on the source as well as the destination machines
should match. If they don't, it means some ports that got hotplugged on
the source aren't instantiated on the destination. Or that ports that
were hot-unplugged on the source are created on the destination.
Signed-off-by: Amit S
The virtio-serial code doesn't mix declarations and definitions, so
separate them out on different lines.
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index bb11a9b
If some ports that were hot-plugged on the source are not available on
the destination, fail migration instead of trying to deref a NULL
pointer.
Signed-off-by: Amit Shah
Reported-by: Juan Quintela
---
hw/virtio-serial-bus.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff
The check for a 0-sized write request to a guest port is not necessary;
the while loop below won't be executed in this case and all will be
fine.
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-serial-bus.c
Allow the port 'id's to be set by a user on the command line. This is
needed by management apps that will want a stable port numbering scheme
for hot-plug/unplug and migration.
Since the port numbers are shared with the guest (to identify ports in
control messages), we just send a control message
Signed-off-by: Amit Shah
---
hw/virtio-console.c|2 +-
hw/virtio-serial-bus.c |2 +-
hw/virtio-serial.h |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index 17b221d..6b8 100644
--- a/hw/virtio-console.c
+++ b
If adding of ports or devices in the guest fails we can send out a QMP
event so that management software can deal with it.
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-ser
Data should be written only when ports are open.
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 3a09f0d..6befd4d 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/vi
The virtio-net code uses iov_fill() which fills an iov from a linear
buffer. The virtio-serial-bus code does something similar in an
open-coded function.
Create a new iov.c file that has iov_from_buf().
Convert virtio-net and virtio-serial-bus over to use this functionality.
virtio-net used ints
iov_to_buf() puts the buffer contents in the iov in a linearized buffer.
iov_size() gets the length of the contents in the iov.
The iov_to_buf() function is the memcpy_to_iovec() function that was
used in virtio-ballon.c.
Signed-off-by: Amit Shah
---
hw/iov.c| 37
Current control messages are small enough to not be split into multiple
buffers but we could run into such a situation in the future or a
malicious guest could cause such a situation.
So handle the entire iov request for control messages.
Also ensure the size of the control request is >= what we
Current guests don't send more than one iov but it can change later.
Ensure we handle that case.
Signed-off-by: Amit Shah
CC: Avi Kivity
---
hw/virtio-serial-bus.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
Before the earlier patch, we relied on incorrect virtio api usage to
signal to the guest that a particular buffer wasn't consumed by the
host.
After fixing that, we now just discard the data the guest sends us while
a host port is disconnected or doesn't have a handler registered for
consuming dat
Individual ports can now signal to the virtio-serial core to stop
sending data if the ports cannot immediately handle new data. When a
port later unthrottles, any data queued up in the virtqueue are sent to
the port.
Disable throttling once a port is closed (and we discard all the
unconsumed buff
We cannot indicate to the guest how much data was consumed by an app for
out_bufs. So we just have to assume the apps will consume all the data
that are handed over to them.
Fix the virtio api abuse in control_out() and handle_output().
Signed-off-by: Amit Shah
---
hw/virtio-console.c|
If the host connection to a port is closed on the destination machine
after migration, whereas the connection was open on the source, the
guest has to be informed of that.
Similar for a host connection open on the destination.
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c | 11 +
86 matches
Mail list logo
