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
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
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
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 00e8616
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
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 +
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 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 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(+
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
>> I was wondering whether something in-between would also
>> be feasible. That is, chunks of guest address space (say 4MB chunks for
>> the sake of the argument) are mmapped into the address space of the Qemu
>> process on the host, and when an access to guest memory is made, there is
>> an initi
On 03/24/2010 12:19 PM, Richard Henderson wrote:
On 03/24/2010 02:47 AM, Paolo Bonzini wrote:
1) make CPUState define only common fields. Include CPUState at the
beginning of each per-target CPUXYZState.
Irritatingly, the common fields contain quite big TLBs. And the
offsets from the start of
The bochs vbe interface got a new register a while back, which specifies
the linear framebuffer size in 64k units. This patch adds support for
the new register to qemu. With this patch applied vgabios 0.6c works
with qemu.
Signed-off-by: Gerd Hoffmann
---
hw/vga.c |3 ++-
hw/vga_int.h
When input some invialid words in QMP port, qemu outputs this error message:
"parse error: invalid keyword `%s'"
This patch makes qemu output the content, like:
"parse error: invalid keyword `unknow_cmd'"
Signed-off-by: Amos Kong
---
json-parser.c |7 ++-
1 files changed, 6 insertions(+
In practice I've seen this not working correctly in the past, i.e. my
^^^
br0 didn't pop up in the virt-manager nic setup page.
Please file a bug: virt-manager has had bridge detection for years, so
something must be going wrong.
W
On 03/24/2010 03:59 AM, Gerd Hoffmann wrote:
> On 03/24/10 00:13, Jamie Lokier wrote:
>> Gerd Hoffmann wrote:
- networking: man, setting networking is a mess, libvirt just does it
for you.
>>>
>>> +1
>>>
>>> Even when not using libvirt for a reason or another I usually hook my
>>> virt
> If the technical documentation at
> http://www.usenix.org/publications/library/proceedings/usenix05/tech/freeni
> x/full_papers/bellard/bellard_html/index.html is still valid (I think it
> is), Qemu has two modes of handling access to guest memory - system
> emulation, in which an entire guest
> > IMO the no_user flag is a bug, and should not exist.
>
> Sorry, what's that?
Usually an indication that a device has been incorrectly or inproperly
converted to the qdev interface.
Paul
On 03/24/2010 07:25 AM, Paul Brook wrote:
I can't quite see what such a libqemu would buy us compared to straight
QMP.
Talking QMP should be easy, provided you got a suitable JSON library.
I agree. My undesranding is this was one of the large motivations behind using
JSON: It's a common p
On 03/24/2010 02:23 PM, Anthony Liguori wrote:
On 03/24/2010 05:42 AM, Avi Kivity wrote:
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it configurable based on UID, policykit, SASL,
On 03/24/2010 02:30 PM, Paul Brook wrote:
On 03/23/2010 09:24 PM, Anthony Liguori wrote:
We also provide an API for guest creation (the qemu command line).
As an aside, I'd like to see all command line options have qmp
equivalents (most of them can be implemented with a 'set' comm
On 03/24/2010 07:27 AM, Avi Kivity wrote:
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client connections
- filters access according to uid (SCM
> On 03/23/2010 09:24 PM, Anthony Liguori wrote:
> > We also provide an API for guest creation (the qemu command line).
>
> As an aside, I'd like to see all command line options have qmp
> equivalents (most of them can be implemented with a 'set' command that
> writes qdev values). This allows a
On 03/24/2010 07:29 AM, Avi Kivity wrote:
On 03/24/2010 02:23 PM, Anthony Liguori wrote:
On 03/24/2010 05:42 AM, Avi Kivity wrote:
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it
On 03/24/2010 02:32 PM, Anthony Liguori wrote:
You don't get a directory filled with a zillion socket files pointing
at dead guests. Agree that's a poor return on investment.
Deleting it on atexit combined with flushing the whole directory at
startup is a pretty reasonable solution to this (
On 03/24/2010 02:30 PM, Anthony Liguori wrote:
On 03/24/2010 07:27 AM, Avi Kivity wrote:
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client conn
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client connections
- filters access according to uid (SCM_CREDENTIALS)
- can pass a new monitor to
> I can't quite see what such a libqemu would buy us compared to straight
> QMP.
>
> Talking QMP should be easy, provided you got a suitable JSON library.
I agree. My undesranding is this was one of the large motivations behind using
JSON: It's a common protocol that already has convenient bindi
On 03/24/2010 05:42 AM, Avi Kivity wrote:
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it configurable based on UID, policykit, SASL,
TLS/x509
already, and intend adding role base
On 03/24/2010 05:17 AM, Amos Kong wrote:
-fprintf(stderr, "parse error: %s\n", msg);
+va_list ap;
+va_start(ap, msg);
+fprintf(stderr, "parse error: ");
+vfprintf(stderr, msg, ap);
+fprintf(stderr, "\n");
Technically you need va_end here.
r~
On 03/24/2010 12:17 AM, Avi Kivity wrote:
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest
enumeration. So the fundamental topic he
When input some invialid words in QMP port, qemu outputs this error message:
"parse error: invalid keyword `%s'"
This patch makes qemu output the content, like:
"parse error: invalid keyword `unknow_cmd'"
Signed-off-by: Amos Kong
---
json-parser.c |7 ++-
1 files changed, 6 insertions(+)
On Tue, Mar 23, 2010 at 12:55:07PM -0700, Badari Pulavarty wrote:
> Michael S. Tsirkin wrote:
>> On Tue, Mar 23, 2010 at 10:57:33AM -0700, Badari Pulavarty wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote:
>
Hello,
This is an idle question in the sense that, much as I would like to, I know for
a
fact that I won't have the time to look at implementing this. I'm not expecting
other people to seriously look at doing it either, but I would be interested on
your
thoughts.
If the technical documentatio
On 03/24/2010 02:47 AM, Paolo Bonzini wrote:
1) make CPUState define only common fields. Include CPUState at the
beginning of each per-target CPUXYZState.
Irritatingly, the common fields contain quite big TLBs. And the
offsets from the start of env affect the compactness of the code
generated
On 03/24/2010 12:36 PM, Daniel P. Berrange wrote:
On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote:
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
I
On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote:
> On 03/23/2010 08:00 PM, Avi Kivity wrote:
> >On 03/23/2010 06:06 PM, Anthony Liguori wrote:
> >>>I thought the monitor protocol *was* our API. If not, why not?
> >>
> >>It is. But our API is missing key components like guest
> >>enumer
On Mon, Mar 22, 2010 at 04:49:21PM -0500, Anthony Liguori wrote:
> On 03/22/2010 03:10 PM, Daniel P. Berrange wrote:
> >>This isn't necessarily libvirt's problem if it's mission is to provide a
> >>common hypervisor API that covers the most commonly used features.
> >>
> >That is more or less
Anthony Liguori writes:
> On 03/23/2010 06:25 PM, Jamie Lokier wrote:
>> Alexander Graf wrote:
>>
>>> I don't see why we shouldn't be able to automatically generate
>>> libqemu.so. We have the *.hx files that describe the syntax of
>>> parameters plus list all available options / commands. I'
On Saturday 20 March 2010 23:00:49 Alexander Graf wrote:
> Am 20.03.2010 um 15:02 schrieb Mohammed Gamal :
> > On Sat, Mar 20, 2010 at 3:18 PM, Avi Kivity wrote:
> >> On 03/20/2010 10:55 AM, Alexander Graf wrote:
> > I'd say that a GSoC project would rather focus on making a guest
> > OS w
Thanks a lot, Juan!
Jun
On Wed, Mar 24, 2010 at 6:41 PM, Juan Quintela wrote:
> Jun Koi wrote:
>> Hi,
>>
>> Is it possible to use -monitor option to expose the monitor on socket
>> interface, such as TCP or Unix domain port, so I can access the
>> monitor using non-stdio way?
>
> man qemu
>
> s
On Tue, Mar 23, 2010 at 12:55:07PM -0700, Badari Pulavarty wrote:
> Michael S. Tsirkin wrote:
>> On Tue, Mar 23, 2010 at 10:57:33AM -0700, Badari Pulavarty wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote:
>
The harder cases are those where the device code depends somehow on
the architecture. Some thoughts follow.
vl.c: a lot of work. Maybe the CPUState stuff should be separated to a new file.
dma.c: DMA_schedule needs access to CPUState.
Most users of CPUState (e.g. qemu-timer.c and hw/dma.c) e
Jun Koi wrote:
> Hi,
>
> Is it possible to use -monitor option to expose the monitor on socket
> interface, such as TCP or Unix domain port, so I can access the
> monitor using non-stdio way?
man qemu
search -monitor
-monitor dev
Redirect the monitor to host device dev (same d
Blue Swirl wrote:
> Hi,
>
> Here's some planning for getting most files compiled as few times as
> possible. Comments and suggestions are welcome.
I took some thought about this at some point. Problems here start from
"Recursive Makefile condered Harmful (tm)".
Look at how we jump through hops
Andi Kleen wrote:
> Juan Quintela writes:
>>
>> - networking: man, setting networking is a mess, libvirt just does it
>> for you.
>
> Agreed it's messy, but isn't this something that the standard qemu
> command line tool could potentially do better by itself? I don't see why you
> need a wrapp
On 03/24/10 00:13, Jamie Lokier wrote:
Gerd Hoffmann wrote:
- networking: man, setting networking is a mess, libvirt just does it
for you.
+1
Even when not using libvirt for a reason or another I usually hook my
virtual machines into virbr0 (libvirt default network).
I had the opposite p
101 - 147 of 147 matches
Mail list logo
