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 uniform
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 here is, do we introduce these
missing compo
On 03/23/2010 09:31 PM, Anthony Liguori wrote:
One problem is that this is libvirt version specific. For example,
libvirt x doesn't support spice so we control that thorough qmp. But
libvirt x+1 does support spice and now it gets confused about all the
spice messages.
That's only a prob
On 03/23/2010 08:23 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 08:00:21PM +0200, 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 gue
Hello,
My name is Aravind. I am working on a project which involves inserting code
to call one of my functions.
This is what it looks like:
//The function to be called.
void log_entry(int reg, int data)
{
printf("REG access\n");
printf("Data got REG = %d and data = %d\n", reg, data);
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?
Thanks a lot,
Jun
Windows XP and 2003 are not installing on current kvm via libvirt, due to an
issue with the drive geometry presented via the BIOS.
They do not reboot, after the first portion of the install.
libvirt version 0.7.6 is utilizing the -drive ... / -device ... command line
arguments to qemu-kvm, which
On (Wed) Mar 24 2010 [11:35:09], Liang YANG wrote:
>
> Last, start the image Guest use qemu-system-x86_64 -net nic,
> model=virtio. This time I can see virtio_net module in GuestOS, but it
> doesn't work. The qemu didn't emulate the virtio net device. So I
> update the code located in pc_init1(),
On Tue, 23 Mar 2010 20:17:33 -0300, Luiz Capitulino
wrote:
> On Tue, 16 Mar 2010 14:44:58 +0530
> "Aneesh Kumar K.V" wrote:
>
> > Hi,
> >
> >
> > This patch series adds a paravirtual file system passthrough mechanism to
> > QEMU
> > based on the 9P protocol. With the current implementation,
Maybe I solove the problem.
I use the qemu-img make a new GustOS img. And install the debian5 on
the image file with option -net nic, model=virtio.
./x86_64-softmmu/qemu-system-x86_64 -hda debian.img -cdrom debian.iso
-net nic, model=virtio
Then I update the kernel image file with virtio, virtio_
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 wrapper for that.
-Andi
--
a...@li
On 03/23/2010 01:23 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 08:00:21PM +0200, 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 gue
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'm not sure
how exactly QMP works, but havin
Avi Kivity wrote:
> >Either way - then we should make the goal of the project to support those
> >old boot loaders. IMHO it should contain visibility. Doing theoretical
> >stuff is just less fun for all parties. Or does that stuff work already?
>
> Mostly those old guests aged beyond usefulness.
> I am involved in a project that we use Qemu user mode for i386
> (./i386-linux-user/qemu-i386). I want to modify the source code
> in such a way to make qemu execute a buffer of bytes (given from the comman
> line for example) rather than loading
> an ELF file and executing. I started looking at
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'm not sure
> how exactly QMP works, but having a generic QMP command to list all
> avail
Anthony Liguori wrote:
> On 03/23/2010 10:57 AM, Paul Brook 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.
Is that simply enumerating running qemu instances, and asking each one
about things like i
Juan Quintela wrote:
> - monitor: I need a way to get to the monitor when going through
> libvirt, in the past you couldn't allow this, but now it looks
> possible.
Now you can just start another monitor connection to qemu :-)
Previously I've used a multiplexing script which accepts multiple
On Tue, 16 Mar 2010 14:44:58 +0530
"Aneesh Kumar K.V" wrote:
> Hi,
>
>
> This patch series adds a paravirtual file system passthrough mechanism to QEMU
> based on the 9P protocol. With the current implementation, all I/O is
> implemented
> in the VCPU thread. We've modified the protocol handl
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 problem. Needed to use mult
Anthony Liguori wrote:
> (like mDNS or SLP). The later mechanism scales better and tends to
> be more robust.
(Aside: mDNS is blocked on some larger networks because it creates too
much load. On those networks, an aggregator is essential - or a
protocol which scales better (less broadcasting)).
Changes from v2 to v3:
* millicode division routines removed in favour of generic code.
r~
Richard Henderson (2):
tcg-hppa: Compute is_write in cpu_signal_handler.
tcg-hppa: Finish the port.
configure |5 +-
cpu-exec.c| 38 +-
tcg/hppa/tcg-target.c | 1758 +
---
cpu-exec.c | 38 +++---
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index bcfcda2..14204f4 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -1193,15 +1193,39 @@ int cpu_signal_handler(int host_signum, void *pinfo,
{
On Mon, 22 Mar 2010 11:38:12 +0100
Markus Armbruster wrote:
> v2: Supply a missing error conversion pointed out by Luiz
It looks ok now.
>
> Markus Armbruster (2):
> qdev: Convert qdev_unplug() to QError
> monitor: convert do_device_del() to QObject, QError
>
> hw/qdev.c | 11 ++
> http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markup&content-type=text/vnd.viewcvs-markup&revision=REL_2_4_2_FINAL
> >
> 2.2.5 December 2005 BeOS boot failure fix in the PCI IDE code
>
> 2.3.5 September 2007 [1500216] Bochs fails to boot BeOs CD
Hmm actually, I begin to think it just
On Mon, 22 Mar 2010 10:48:53 +0100
Markus Armbruster wrote:
> Monitor commands to go with -netdev.
>
> Signed-off-by: Markus Armbruster
> ---
> net.c | 57
> ++-
> net.h |2 +
> qemu-monitor.hx | 30 ++
On Mon, 22 Mar 2010 10:28:59 +0100
Markus Armbruster wrote:
> Cleaner integration of location tracking with qemu-tool.c. Move
> qerror_report() where it belongs.
>
> v2: Remove an assertion that unreachable code can't be reached, at
> Blue Swirl's request. Rebased.
>
> Markus Armbruster (6):
Hi,
Here's some planning for getting most files compiled as few times as
possible. Comments and suggestions are welcome.
I have now converted most of the easy cases which were compiled for
all targets, saving about 200 compiles for full build with default set
of targets (~1500 files compiled). Fo
> http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markup&content-type=text/vnd.viewcvs-markup&revision=REL_2_4_2_FINAL
> >
> 2.2.5 December 2005 BeOS boot failure fix in the PCI IDE code
>
> 2.3.5 September 2007 [1500216] Bochs fails to boot BeOs CD
>
I had a look at it, but it seems it'
On Wed, Mar 17, 2010 at 01:56:07PM +0100, Johan Bengtsson wrote:
> Do not try to insert a conditional jump over next instruction when the
> condition code is AL as this will trigger an internal error.
>
> Signed-off-by: Johan Bengtsson
Thanks, applied.
> ---
> target-arm/translate.c |8 +++
On Wed, Mar 17, 2010 at 07:56:12AM -0700, Richard Henderson wrote:
> On 03/16/2010 06:58 PM, Stuart Brady wrote:
> > The tcg_reg_free() calls worry me slightly, but I assume they're safe...
>
> Yeah, that one's rather gross.
>
> Since Aurelien's generic div/rem patch I could simply remove all
> t
On Sat, Feb 20, 2010 at 11:32:23AM -0800, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
Thanks, applied.
> ---
> tcg/tcg.c | 12 +++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/tcg/tcg.c b/tcg/tcg.c
> index 1818868..d753149 100644
> --- a/tcg/t
On Sat, Feb 20, 2010 at 11:31:31AM -0800, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
Thanks, applied.
> ---
> hppa-dis.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hppa-dis.c b/hppa-dis.c
> index 9d96d72..49f99c8 100644
> --- a/hppa-dis.c
On Fri, Mar 19, 2010 at 11:31:15AM +0100, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini
> ---
> dyngen-exec.h | 26 --
> tcg/arm/tcg-target.h|2 --
> tcg/hppa/tcg-target.h |2 --
> tcg/i386/tcg-target.h |2 --
> tcg/mips/tcg-target.h
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:
Write Results:
==
I see degraded IO performance when doing sequential IO write
Michael S. Tsirkin wrote:
On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote:
Write Results:
==
I see degraded IO performance when doing sequential IO write
tests with vhost-blk compared to virtio-blk.
# time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct
I get ~1
Michael S. Tsirkin wrote:
On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote:
Write Results:
==
I see degraded IO performance when doing sequential IO write
tests with vhost-blk compared to virtio-blk.
# time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct
I get ~1
I use the qemu-kvm-0.12-3 version source file. Just follow the typical
three steps: ./configure && make && make install.
After I configure, following is output:
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
Manual directory /usr/local/share
Hi,
I read, that it´s possible, to emulate an x64-Processor with QEMU on an
x86-based PC, isn´t it.
When I run the installation of Ubuntu-9.10-x64 under Qemu-Manager 6.0 under
Windows-XP, I always get an storage-error.
Who can help me, to solve that problem?
With best regards,
Christoph Funda
Hi, all.
I have just touched QEMU and I am doing experiments of malware using the
emulator.
I need some development docs for reference.
Appreciate your help.
Hi,
Inspired by vhost-net implementation, I did initial prototype
of vhost-blk to see if it provides any benefits over QEMU virtio-blk.
I haven't handled all the error cases, fixed naming conventions etc.,
but the implementation is stable to play with. I tried not to deviate
from vhost-net implem
Two new monitor commands: adding ability to handle which keyboard qemu will
use and to see which keyboard are currently available.
$ info keyboard
$ keyboard_set
Signed-off-by: Shahar Havivi
---
console.h |4 ++
input.c | 104 +
Anthony Liguori writes:
> Hi,
>
> On 03/23/2010 02:24 PM, Blue Swirl wrote:
>> On 3/23/10, Aurelien Jarno wrote:
>>
>>> On Tue, Mar 23, 2010 at 03:27:26AM +0100, Aurelien Jarno wrote:
>>> > On Mon, Mar 22, 2010 at 10:25:24PM +0100, Juergen Lock wrote:
>>> > > Hi!
>>> > >
>>> > >
Currently you get segfault when trying to remove keyboard (device_del
monitor command) because no keyboard handling is done.
This patch add QEMUPutKbdEntry structure, handling each keyboard entry.
Adding a keyboard add to the list, removing keyboard select the previous
keyboard in list.
Signed-of
* After Anthony patches, and Luiz comments
Qemu support for multiple keyboard devices:
Patch #1 adding keyboard is done to list instead of "last added keyboard
wins", when removing keyboard via device_del - next keyboard
selected.
Patch #2 adding 2 new monitor command to handl
Thanks, applied.
On 3/22/10, Juergen Lock wrote:
> Signed-off-by: Juergen Lock
>
> --- a/bsd-user/main.c
> +++ b/bsd-user/main.c
> @@ -759,6 +759,10 @@ int main(int argc, char **argv)
> }
>
> cpu_model = NULL;
> +#if defined(cpudef_setup)
> +cpudef_setup(); /* parse cpu defini
On 03/23/2010 01:07 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote:
On 03/23/2010 10:57 AM, Paul Brook wrote:
I think there is a serious divergence of approach there, instanciating
API stating 'we are gonna deprecate them sooner or later'
On 03/23/2010 01: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 here is, do we introduce these
missing compo
Thanks, applied. I've checked that the other parts of the commit don't
have the same problem. Sorry for the trouble.
On 3/23/10, Lars Munch wrote:
>
> This fixes a copy/paste bug introduced in commit
> 2d48377a8531de63ec1d0c4b9b1959dc4b78356c that pushed TARGET_WORDS_BIGENDIAN
> dependency to
On 03/23/2010 12:57 PM, Avi Kivity wrote:
On 03/22/2010 09:25 PM, Anthony Liguori wrote:
Hi,
I've mentioned this to a few folks already but I wanted to start a
proper thread.
We're struggling in qemu with usability and one area that concerns me
is the disparity in features that are supporte
On 3/23/10, Michael Qiu wrote:
> Hi,
> Can anyone tell me what subpage for in exec.c?
It's there so that several devices can register MMIO ranges that
happen to be in the same target physical page.
Hi,
On 03/23/2010 02:24 PM, Blue Swirl wrote:
On 3/23/10, Aurelien Jarno wrote:
On Tue, Mar 23, 2010 at 03:27:26AM +0100, Aurelien Jarno wrote:
> On Mon, Mar 22, 2010 at 10:25:24PM +0100, Juergen Lock wrote:
> > Hi!
> >
> > I just wanted to make another FreeBSD qemu git head
On 3/23/10, Aurelien Jarno wrote:
> On Tue, Mar 23, 2010 at 03:27:26AM +0100, Aurelien Jarno wrote:
> > On Mon, Mar 22, 2010 at 10:25:24PM +0100, Juergen Lock wrote:
> > > Hi!
> > >
> > > I just wanted to make another FreeBSD qemu git head snaphot port update,
> > > and found both i386-softm
On Tue, Mar 23, 2010 at 08:00:21PM +0200, 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 here is, do we i
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:
>>
>>> Write Results:
>>> ==
>>>
>>> I see degraded IO performance when doing sequential IO write
>>> tests with vhost-bl
On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote:
> On 03/23/2010 10:57 AM, Paul Brook wrote:
> >>>I think there is a serious divergence of approach there, instanciating
> >>>API stating 'we are gonna deprecate them sooner or later' tell the
> >>>application developper 'my time is mo
Signed-off-by: Markus Armbruster
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 560e70d..05ea9de 100644
--- a/qerror.c
+++ b/qerror.c
@@ -141,6 +141,10 @@ static const QErrorStringTable qerror_table[] = {
Human monitor error message changes from "unknown migration protocol:
FOO" to "Invalid parameter uri".
The conversion is shallow: the FOO_start_outgoing_migration() aren't
converted. Converting them is a big job for relatively little
practical benefit, so leave it for later.
Signed-off-by: Marku
Markus Armbruster (3):
QError: New QERR_MIGRATION_IN_PROGRESS
QError: New QERR_MIGRATION_FAILED
monitor: Convert do_migrate() to QError
migration.c |9 +
qerror.c|8
qerror.h|6 ++
3 files changed, 19 insertions(+), 4 deletions(-)
Signed-off-by: Markus Armbruster
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 8d885cd..560e70d 100644
--- a/qerror.c
+++ b/qerror.c
@@ -141,6 +141,10 @@ static const QErrorStringTable qerror_table[] = {
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 here is, do we introduce these missing
components to allow people to build directly to
On 03/22/2010 09:25 PM, Anthony Liguori wrote:
Hi,
I've mentioned this to a few folks already but I wanted to start a
proper thread.
We're struggling in qemu with usability and one area that concerns me
is the disparity in features that are supported by qemu vs what's
implemented in libvirt
Hello,
I am involved in a project that we use Qemu user mode for i386
(./i386-linux-user/qemu-i386). I want to modify the source code
in such a way to make qemu execute a buffer of bytes (given from the comman
line for example) rather than loading
an ELF file and executing. I started looking at li
Hi,
Can anyone tell me what subpage for in exec.c?
Best regards
On Tue, Mar 23, 2010 at 09:45:08PM +0530, Amit Shah wrote:
> On (Tue) Mar 23 2010 [17:51:26], Michael S. Tsirkin wrote:
> > On Mon, Mar 22, 2010 at 10:48:02AM +0530, Amit Shah wrote:
> > > On (Sat) Mar 20 2010 [09:40:50], Avi Kivity wrote:
> > > > On 03/19/2010 01:58 PM, Amit Shah wrote:
> > > >> +
This fixes a copy/paste bug introduced in commit
2d48377a8531de63ec1d0c4b9b1959dc4b78356c that pushed TARGET_WORDS_BIGENDIAN
dependency to board level.
Signed-off-by: Lars Munch
---
hw/pxa2xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
i
On (Tue) Mar 23 2010 [17:51:26], Michael S. Tsirkin wrote:
> On Mon, Mar 22, 2010 at 10:48:02AM +0530, Amit Shah wrote:
> > On (Sat) Mar 20 2010 [09:40:50], Avi Kivity wrote:
> > > On 03/19/2010 01:58 PM, Amit Shah wrote:
> > >> +
> > >> +offset = 0;
> > >> +for (i = 0; i< elem.out
> > I think there is a serious divergence of approach there, instanciating
> > API stating 'we are gonna deprecate them sooner or later' tell the
> > application developper 'my time is more important than yours' and not
> > really something I like to carry to the API users.
> > The main goal of lib
On Mon, Mar 22, 2010 at 10:48:02AM +0530, Amit Shah wrote:
> On (Sat) Mar 20 2010 [09:40:50], Avi Kivity wrote:
> > On 03/19/2010 01:58 PM, Amit Shah wrote:
> >> +
> >> +offset = 0;
> >> +for (i = 0; i< elem.out_num; i++) {
> >> +memcpy(buf + offset, elem.out_sg[i].iov_
On 03/23/2010 10:57 AM, Paul Brook wrote:
I think there is a serious divergence of approach there, instanciating
API stating 'we are gonna deprecate them sooner or later' tell the
application developper 'my time is more important than yours' and not
really something I like to carry to the API use
On (Tue) Mar 23 2010 [20:00:19], Amit Shah wrote:
> @@ -369,16 +370,23 @@ static void handle_output(VirtIODevice *vdev, VirtQueue
> *vq)
> * with it. Just ignore the data in that case.
> */
> if (!port->info->have_data) {
> -ret = 0;
> goto nex
migration (we didn't end last week)
- monotonic increasing version doesn't capture individual features
(backporting features may not require earlier features, now id is
incorrect)
- use subsections
- can create new namespace within subsection (ide/$featre/$distro)
- would need to coor
On 03/23/2010 09:51 AM, Daniel Veillard wrote:
On Mon, Mar 22, 2010 at 02:25:00PM -0500, Anthony Liguori wrote:
Hi,
Hi Anthony,
I've mentioned this to a few folks already but I wanted to start a
proper thread.
We're struggling in qemu with usability and one area that concern
Amit Shah wrote:
> 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
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 | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-s
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
If the host connection to a port is closed on the destination machine
after migration, when the connection was open on the source, the host
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 +++
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 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
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 bd44ec6..e915491 100644
--- a/hw/virtio-console.c
+++ b
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
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 | 10 +-
1 files changed, 9 insertions(+), 1
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
Hello,
[any reason you dropped the CC list? CC'ing qemu-devel, where this is
relevant.]
On (Tue) Mar 23 2010 [21:46:28], Liang YANG wrote:
> I check the 'lspci -v' result, only find RTL-8139 realtek ethernet. I
> think the option model=virtio does't make effect.
Then something is wrong. I get a
Juan Quintela wrote:
> Chris Wright wrote:
>> Please send in any agenda items you are interested in covering.
>>
>> Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.
>
> - migration (we didn't end last week)
I told last Tuesday that I will look at the latest vmstate cha
> It's a known bug but nobody knows or has time to apply a solution.
>
> Bochs had the same bug and corrected it about November 2009, maybe
> checking their commit will make light to correct QEMU.
Ok, I might have a look at it, thanks.
> > It seems VirtualBox has the same issue. Older versions (Z
On 03/23/10 13:45, Anthony Liguori wrote:
I don't think we can pull in:
- extboot
- ia64
- in-kernel pit[1]
- associated command line options
- device passthrough
The question is, if we dropped those things, would people actually use
qemu.git instead of qemu-kvm.git. If the answer is "no", what
s present on BeOS R3, R4, R4.5 and R5.
The warning suggest the block device is seen as having a size of 0,
though oddly it seems to be able to read from it since it gets the
size
of the BFS in the superblock...
I've rebuilt with DEBUG_IDE and put a log here:
http://revolf.free.fr/beos/qem
On 03/23/2010 02:45 PM, Anthony Liguori wrote:
On 03/23/2010 04:52 AM, Avi Kivity wrote:
On 03/23/2010 11:31 AM, Jan Kiszka wrote:
Chris Wright wrote:
Please send in any agenda items you are interested in covering.
Yes, usability is a valid topic esp. if you promise to come w/ GUI
patches.
On 03/23/2010 04:52 AM, Avi Kivity wrote:
On 03/23/2010 11:31 AM, Jan Kiszka wrote:
Chris Wright wrote:
Please send in any agenda items you are interested in covering.
Yes, usability is a valid topic esp. if you promise to come w/ GUI
patches.
- state and roadmap for upstream merge of in-k
On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote:
> Write Results:
> ==
>
> I see degraded IO performance when doing sequential IO write
> tests with vhost-blk compared to virtio-blk.
>
> # time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct
>
> I get ~110MB/sec with
On 03/23/2010 01:11 AM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.
I can't make today's call. I'd hoping there's a discussion about
libqemu and libvirt though and that som
"Michael S. Tsirkin" wrote:
> On Tue, Mar 23, 2010 at 11:40:46AM +, Paul Brook wrote:
>> > > Right. The only real challenge is dealing with legacy save/restore and
>> > > command line syntax. For save/restore, we can possibly have a dummy
>> > > device that can split the VirtioPCI device sta
On 03/23/2010 01:13 PM, Jan Kiszka wrote:
The benefit would be that qemu-kvm.git would become a staging tree
instead of the master repository for kvm users. As an example, we
wouldn't have any bisectability problems. kvm features would need to be
written just once.
The last item would
Hi,
I read, that it´s possible, to emulate an x64-Processor with QEMU on an
x86-based PC, isn´t it.
When I run the installation of Ubuntu-9.10-x64 under Qemu-Manager 6.0 under
Windows-XP, I always get an storage-error.
Who can help me, to solve that problem?
With best regards,
Christoph Funda
"Daniel P. Berrange" wrote:
> On Tue, Mar 23, 2010 at 11:50:57AM +0100, Juan Quintela 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 h
On Tue, Mar 23, 2010 at 11:40:46AM +, Paul Brook wrote:
> > > Right. The only real challenge is dealing with legacy save/restore and
> > > command line syntax. For save/restore, we can possibly have a dummy
> > > device that can split the VirtioPCI device state from the virtio device
> > > st
> > Right. The only real challenge is dealing with legacy save/restore and
> > command line syntax. For save/restore, we can possibly have a dummy
> > device that can split the VirtioPCI device state from the virtio device
> > states and do the right thing.
> >
> > I'm not sure what we should do
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
1 - 100 of 135 matches
Mail list logo
