Hi,
I am writing a tracing back-end that logs tracepoint-based traces to
qemu-internal global buffers.
I had zeroed in on a lockless buffer for logging traces(to prevent
slowdowns 'cos of locks held while tracing). However, I'm not sure if
qemu threads might need some synchronisation to access
At Tue, 25 May 2010 10:12:53 -0700 (PDT),
Sage Weil wrote:
>
> On Tue, 25 May 2010, Avi Kivity wrote:
> > > What's the reason for not having these drivers upstream? Do we gain
> > > anything by hiding them from our users and requiring them to install the
> > > drivers separately from somewhere els
Hi,
I'm trying to migrate a guest device with MSI-X interrupts. However,
the interrupts are not injected into the guest. I've added some
tracing to msix.c and it seems that the MSI-X vectors are masked when
the guest is resumed (I'm testing with static migration).
In particular, in msix.c, msix
On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
I really think this patch can be useful, in my own case when testing
debian-installer (I already cache=writeback). In short all that is about
developing and testing, as opposed to run a VM in production, can
benefit about that. This was one of the or
At Tue, 25 May 2010 15:43:17 +0200,
Kevin Wolf wrote:
>
> Am 24.05.2010 08:34, schrieb MORITA Kazutaka:
> > At Fri, 21 May 2010 18:57:36 +0200,
> > Kevin Wolf wrote:
> >>
> >> Am 20.05.2010 07:36, schrieb MORITA Kazutaka:
> >>> +
> >>> +/*
> >>> + * Append an option list (list) to an option list (
Anthony Liguori wrote:
> On 05/25/2010 02:09 PM, Blue Swirl wrote:
>> On Mon, May 24, 2010 at 8:13 PM, Jan Kiszka wrote:
>>
>>> From: Jan Kiszka
>>>
>>> This allows to communicate potential IRQ coalescing during delivery from
>>> the sink back to the source. Targets that support IRQ coalescing
On Tue, May 25, 2010 at 07:59:18PM +0200, Alexander Graf wrote:
> Anthony Liguori wrote:
> > On 05/17/2010 11:23 AM, Paul Brook wrote:
> I don't see a difference between the results. Apparently the barrier
> option doesn't change a thing.
>
> >>> Ok. I don't like it, but I c
On 05/25/2010 02:09 PM, Blue Swirl wrote:
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszka wrote:
From: Jan Kiszka
This allows to communicate potential IRQ coalescing during delivery from
the sink back to the source. Targets that support IRQ coalescing
workarounds need to register handlers that
On Mon, May 24, 2010 at 2:17 AM, Yehuda Sadeh Weinraub
wrote:
> On Sun, May 23, 2010 at 12:59 AM, Blue Swirl wrote:
>> On Thu, May 20, 2010 at 11:02 PM, Yehuda Sadeh Weinraub
>> wrote:
>>> On Thu, May 20, 2010 at 1:31 PM, Blue Swirl wrote:
On Wed, May 19, 2010 at 7:22 PM, Christian Brunner
Fixed now. In the future, please use the discussion page on the wiki to
report bad links
** Changed in: qemu
Status: New => Fix Released
--
Documentation link is broken
https://bugs.launchpad.net/bugs/585529
You received this bug notification because you are a member of qemu-
devel-ml, w
On Tue, May 25, 2010 at 7:20 PM, Prerna Saxena
wrote:
>> Some added lines of code use tabs for indentation, 4 space indentation
>> should
>> be used.
>>
>> +struct tracepoint {
>> + char *name; /* Tracepoint name */
>> + uint8_t trace_id; /* numerical
On Tue, May 25, 2010 at 5:00 PM, Artyom Tarasenko
wrote:
> 2010/5/21 Blue Swirl :
>> On Fri, May 21, 2010 at 5:23 PM, Artyom Tarasenko
>> wrote:
>>> 2010/5/10 Blue Swirl :
On 5/10/10, Artyom Tarasenko wrote:
> 2010/5/10 Blue Swirl :
>
> > On 5/10/10, Artyom Tarasenko wrote:
>>>
On Mon, May 24, 2010 at 12:34 AM, Blue Swirl wrote:
> BROKEN
>
> Signed-off-by: Blue Swirl
> ---
> cpu-common.h | 3 +-
> softmmu_template.h | 69
> ++--
> 2 files changed, 63 insertions(+), 9 deletions(-)
Changes to io_read and io_wri
On Tue, May 25, 2010 at 11:24 PM, Blue Swirl wrote:
> On Tue, May 25, 2010 at 12:09 PM, Igor V. Kovalenko
> wrote:
>> From: Igor V. Kovalenko
>>
>> - remove unused host state and store pci bus pointer only
>> - do not map host state access into unused 1fe.1000 range
>> - reorder pci region r
25.05.2010 15:03, Peter Lieven wrote:
Michael Tokarev wrote:
23.05.2010 13:55, Peter Lieven wrote:
[]
[64442.298521] irq 10: nobody cared (try booting with the "irqpoll" option)
[]
[64442.299433] handlers:
[64442.299840] [] (e1000_intr+0x0/0x190 [e1000])
[64442.300046] Disabling IRQ #10
Ap
Public bug reported:
Sorry, did not know where else to send this. I could not find a "contact
us" page for QEMU.
The link to "QEMU Documentation" on the page http://wiki.qemu.org/Manual
is broken. It points to "http://wiki.qemu.org/download/qemu-doc.html";
which does not currently exist.
** Affe
On Tue, May 25, 2010 at 12:09 PM, Igor V. Kovalenko
wrote:
> From: Igor V. Kovalenko
>
> - remove unused host state and store pci bus pointer only
> - do not map host state access into unused 1fe.1000 range
> - reorder pci region registration
> - assign pci i/o region to isa_mem_base
Looks g
On Tue, May 25, 2010 at 8:39 AM, Joerg Roedel wrote:
> On Mon, May 24, 2010 at 08:10:16PM +, Blue Swirl wrote:
>> On Mon, May 24, 2010 at 3:40 PM, Joerg Roedel wrote:
>> >> +
>> >> +#define MMIO_SIZE 0x2028
>> >
>> > This size should be a power-of-two value. In this case probabl
On Mon, May 24, 2010 at 8:13 PM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> This allows to communicate potential IRQ coalescing during delivery from
> the sink back to the source. Targets that support IRQ coalescing
> workarounds need to register handlers that return the appropriate
> QEMU_IRQ_* co
Anthony Liguori wrote:
> On 05/25/2010 12:59 PM, Alexander Graf wrote:
>>> I see it as the equivalent to the Taint bit in Linux. I want to make
>>> it clear to users up front that if you use this option, and you have
>>> data loss issues, don't complain.
>>>
>>> Just putting something in qemu-doc.
On 05/25/2010 01:37 PM, Juan Quintela wrote:
Luiz Capitulino wrote:
On Tue, 25 May 2010 16:21:01 +0200
Juan Quintela wrote:
Signed-off-by: Juan Quintela
---
migration.c | 16 ++--
migration.h |2 +-
vl.c|7 ++-
3 files changed, 17 insertions(+
On 05/25/2010 01:31 PM, Luiz Capitulino wrote:
On Tue, 25 May 2010 16:21:03 +0200
Juan Quintela wrote:
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintela
---
QMP/qmp-events.txt | 50 +
On 05/25/2010 12:59 PM, Alexander Graf wrote:
I see it as the equivalent to the Taint bit in Linux. I want to make
it clear to users up front that if you use this option, and you have
data loss issues, don't complain.
Just putting something in qemu-doc.texi is not enough IMHO. Few
people actua
Luiz Capitulino wrote:
> On Tue, 25 May 2010 16:21:01 +0200
> Juan Quintela wrote:
>
>> Signed-off-by: Juan Quintela
>> ---
>> migration.c | 16 ++--
>> migration.h |2 +-
>> vl.c|7 ++-
>> 3 files changed, 17 insertions(+), 8 deletions(-)
>>
> While I agree
Luiz Capitulino wrote:
> On Tue, 25 May 2010 17:35:53 +0200
> Juan Quintela wrote:
>
>> Anthony Liguori wrote:
>> > On 05/25/2010 09:21 AM, Juan Quintela wrote:
>>
>> >> +MIGRATION_CANCELED
>> >> +--
>> >> +
>> >> +Emitted when migration is canceled. This is emitted in the sour
On Mon, May 24, 2010 at 8:46 PM, Venkateswararao Jujjuri (JV)
wrote:
> Blue Swirl wrote:
>> Field d_off in struct dirent is Linux specific.
>>
>> Signed-off-by: Blue Swirl
>> ---
>> Makefile.objs | 8
>> Makefile.target | 2 +-
>> hw/virtio-9p.c | 2 +-
>> hw/virtio-pci.c |
On Tue, 25 May 2010 16:21:03 +0200
Juan Quintela wrote:
> They are emitted when migration starts, ends, has a failure or is canceled.
>
> Signed-off-by: Juan Quintela
> ---
> QMP/qmp-events.txt | 50 ++
> monitor.c | 12
On Tue, 25 May 2010 17:35:53 +0200
Juan Quintela wrote:
> Anthony Liguori wrote:
> > On 05/25/2010 09:21 AM, Juan Quintela wrote:
>
> >> +MIGRATION_CANCELED
> >> +--
> >> +
> >> +Emitted when migration is canceled. This is emitted in the source.
> >> +Target will emit MIGRATION
Hi Stefan,
Thanks for having a look.
As I'd mentioned, this patchset is *work in progress*, which explains
the dummy comments and coding style violations at places :) I was merely
sharing a draft of what my approach is -- so that we can work together
on how much of it can add to the trace frame
On Tue, 25 May 2010 11:10:23 -0500
Anthony Liguori wrote:
> There should be some information about why it failed, no? Preferrably
> in a QError format.
>
>
> >>> At this point, we have basically -1 :(
> >>>
> >>> I can add a field with an error number, but we are ver
On Fri, 21 May 2010 14:26:05 -0700
"Venkateswararao Jujjuri (JV)" wrote:
Hi JV,
While I agree that this patch is nice to have, why is this part of the
security model patchset? Is it required to implement the models?
Thanks,
Sripathi.
> Signed-off-by: Venkateswararao Jujjuri
> ---
> hw/virtio
On Tue, 25 May 2010 16:21:01 +0200
Juan Quintela wrote:
> Signed-off-by: Juan Quintela
> ---
> migration.c | 16 ++--
> migration.h |2 +-
> vl.c|7 ++-
> 3 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/migration.c b/migration.c
> index 05f6
Anthony Liguori wrote:
> On 05/17/2010 11:23 AM, Paul Brook wrote:
I don't see a difference between the results. Apparently the barrier
option doesn't change a thing.
>>> Ok. I don't like it, but I can see how it's compelling. I'd like to
>>> see the documentation improved
Anthony Liguori wrote:
> On 05/25/2010 11:25 AM, Daniel P. Berrange wrote:
>> On Tue, May 25, 2010 at 06:04:17PM +0200, Juan Quintela wrote:
>>
>>> Anthony Liguori wrote:
> I'm not sure why you would need a notification of when migration
> starts (since you know when you've started migration
On Tue, 25 May 2010, Avi Kivity wrote:
> > What's the reason for not having these drivers upstream? Do we gain
> > anything by hiding them from our users and requiring them to install the
> > drivers separately from somewhere else?
> >
>
> Six months.
FWIW, we (Ceph) aren't complaining about
2010/5/21 Blue Swirl :
> On Fri, May 21, 2010 at 5:23 PM, Artyom Tarasenko
> wrote:
>> 2010/5/10 Blue Swirl :
>>> On 5/10/10, Artyom Tarasenko wrote:
2010/5/10 Blue Swirl :
> On 5/10/10, Artyom Tarasenko wrote:
>> 2010/5/9 Blue Swirl :
>> > On 5/9/10, Artyom Tarasenko
On Tue, May 25, 2010 at 6:25 PM, Gerd Hoffmann wrote:
> In case the desktop did resize while the vnc connection setup was still
> in progress the client isn't informed about it. Send a desktop resize
> event as soon as the client told us it can handle deskop resize via set
> encodings message to
On 05/25/2010 07:21 PM, Anthony Liguori wrote:
On 05/25/2010 11:16 AM, Avi Kivity wrote:
On 05/25/2010 06:01 PM, Anthony Liguori wrote:
On 05/25/2010 10:00 AM, Avi Kivity wrote:
The latter. Why is it less important? If you don't inherit the
memory, you can't access it.
You can also pass /d
Add two new variables to keep track of the vnc clients desktop size.
Signed-off-by: Gerd Hoffmann
---
vnc.c | 10 +++---
vnc.h |2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/vnc.c b/vnc.c
index 0e0e566..30e0bed 100644
--- a/vnc.c
+++ b/vnc.c
@@ -521,10 +521,12 @@
Hi,
This series brings a bunch of vnc desktop size patches, fixing the
issues discussed in the "Possible race condition in VNC display
resizing" thread. Check list archive here:
http://lists.gnu.org/archive/html/qemu-devel/2010-04/msg01778.html
cheers,
Gerd
Gerd Hoffmann (5):
vnc: factor
Don't send updates for screen areas which are outside the clients
desktop. May happed with vnc clients which don't support the desktop
resize message.
Signed-off-by: Gerd Hoffmann
---
vnc.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/vnc.c b/vnc.c
index 30e0b
On Tue, May 25, 2010 at 06:04:17PM +0200, Juan Quintela wrote:
> Anthony Liguori wrote:
> > On 05/25/2010 10:35 AM, Juan Quintela wrote:
>
> >> problem here is that libvirt start target with -S, and waits to do the
> >> "cont" as soon as possible. As of know, only way to do it is to poll
> >> in
On 05/25/2010 11:25 AM, Daniel P. Berrange wrote:
On Tue, May 25, 2010 at 06:04:17PM +0200, Juan Quintela wrote:
Anthony Liguori wrote:
On 05/25/2010 10:35 AM, Juan Quintela wrote:
problem here is that libvirt start target with -S, and waits to do the
"cont" as soon as
In case the desktop did resize while the vnc connection setup was still
in progress the client isn't informed about it. Send a desktop resize
event as soon as the client told us it can handle deskop resize via set
encodings message to make sure the client us up to date.
Signed-off-by: Gerd Hoffma
This make sure we send a desktop resize message only in case we actually
have to, using the new variables which track the clients desktop size.
Signed-off-by: Gerd Hoffmann
---
vnc.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/vnc.c b/vnc.c
index 119ffe8..5
On 05/25/2010 05:01 PM, Kevin Wolf wrote:
The current situation is that those block format drivers only exist in
qemu.git or as patches. Surely that's even more unhappiness.
The difference is that in the current situation these drivers will be
part of the next qemu release, so the patch
On 05/25/2010 11:16 AM, Avi Kivity wrote:
On 05/25/2010 06:01 PM, Anthony Liguori wrote:
On 05/25/2010 10:00 AM, Avi Kivity wrote:
The latter. Why is it less important? If you don't inherit the
memory, you can't access it.
You can also pass /dev/shm fd's via SCM_RIGHTs to establish shared
Signed-off-by: Gerd Hoffmann
---
vnc.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/vnc.c b/vnc.c
index 11ae3e5..aaebe24 100644
--- a/vnc.c
+++ b/vnc.c
@@ -514,6 +514,21 @@ void buffer_append(Buffer *buffer, const void *data,
size_t len)
On 05/25/2010 06:01 PM, Anthony Liguori wrote:
On 05/25/2010 10:00 AM, Avi Kivity wrote:
The latter. Why is it less important? If you don't inherit the
memory, you can't access it.
You can also pass /dev/shm fd's via SCM_RIGHTs to establish shared
memory segments dynamically.
Doesn't work
Please report this bug against libvirt as this does not appear to be an
upstream qemu issue.
** Changed in: qemu
Status: New => Invalid
--
'Broken pipe' error when starting a vm
https://bugs.launchpad.net/bugs/585449
You received this bug notification because you are a member of qemu-
dev
On 05/25/2010 11:04 AM, Juan Quintela wrote:
Anthony Liguori wrote:
On 05/25/2010 10:35 AM, Juan Quintela wrote:
problem here is that libvirt start target with -S, and waits to do the
"cont" as soon as possible. As of know, only way to do it is to poll
info migrate on source fas
Anthony Liguori wrote:
> On 05/25/2010 10:35 AM, Juan Quintela wrote:
>> problem here is that libvirt start target with -S, and waits to do the
>> "cont" as soon as possible. As of know, only way to do it is to poll
>> info migrate on source faster.
>>
>
> Why does it do that??
>
> That soun
On Tue, May 25, 2010 at 10:57:33AM -0500, Anthony Liguori wrote:
> On 05/25/2010 10:35 AM, Juan Quintela wrote:
> >Anthony Liguori wrote:
> >
> >
> >>
> >>>+Data: None
> >>>+
> >>>+Example:
> >>>+
> >>>+{ "event": "MIGRATION_CANCELED",
> >>>+"timestamp": {"seconds": 1274687575, "mic
Anthony Liguori wrote:
> On 05/25/2010 10:35 AM, Juan Quintela wrote:
>> problem here is that libvirt start target with -S, and waits to do the
>> "cont" as soon as possible. As of know, only way to do it is to poll
>> info migrate on source faster.
>>
>
> Why does it do that??
>
> That soun
On 05/25/2010 10:53 AM, Michael Tokarev wrote:
Initially it were a bugreport on #kvm IRC, someone
asked why his kvm exits when entering fullscreen mode,
saying the famous
"Could not open SDL display"
and nothing more.
I added a bit of debug output and here's what I see:
...
resizing to 1440x90
** Project changed: qemu => libvirt
--
'Broken pipe' error when starting a vm
https://bugs.launchpad.net/bugs/585449
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in libvirt virtualization API: Invalid
Bug description:
Occasio
On 05/25/2010 10:35 AM, Juan Quintela wrote:
Anthony Liguori wrote:
On 05/25/2010 09:21 AM, Juan Quintela wrote:
+MIGRATION_CANCELED
+--
+
+Emitted when migration is canceled. This is emitted in the source.
+Target will emit MIGRATION_FAILED (no way to differenti
Initially it were a bugreport on #kvm IRC, someone
asked why his kvm exits when entering fullscreen mode,
saying the famous
"Could not open SDL display"
and nothing more.
I added a bit of debug output and here's what I see:
...
resizing to 1440x900 0 0x115
resizing to 1440x900 32 0x8115
Cou
On Tue, May 25, 2010 at 05:35:53PM +0200, Juan Quintela wrote:
> Anthony Liguori wrote:
>
> >> +Example:
> >> +
> >> +{ "event": "MIGRATION_FAILED",
> >> +"timestamp": {"seconds": 1274687575, "microseconds": 592483} }
> >> +
> >> +MIGRATION_STARTED
> >> +-
> >> +
> >> +Emitted
On Tue, May 25, 2010 at 10:09:55AM -0500, Anthony Liguori wrote:
> On 05/25/2010 09:21 AM, Juan Quintela wrote:
> >They are emitted when migration starts, ends, has a failure or is canceled.
> >
> >+Data: None
> >+
> >+Example:
> >+
> >+{ "event": "MIGRATION_CANCELED",
> >+"timestamp": {"second
Anthony Liguori wrote:
> On 05/25/2010 09:21 AM, Juan Quintela wrote:
>> +MIGRATION_CANCELED
>> +--
>> +
>> +Emitted when migration is canceled. This is emitted in the source.
>> +Target will emit MIGRATION_FAILED (no way to differentiate a FAILED
>> +and CANCELED migration for t
** Attachment added: "virt-manager.log"
http://launchpadlibrarian.net/49083168/virt-manager.log
--
'Broken pipe' error when starting a vm
https://bugs.launchpad.net/bugs/585449
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status
Public bug reported:
Occasionally get an error 'libvir: Remote error : cannot send data:
Broken pipe' scrolling down the screen when starting a VM. VM does not
start and end up having to reboot server to be able to get vm going
again
virsh -q -c qemu:///system start dev32
libvir: QEMU error : s
On 05/25/2010 09:21 AM, Juan Quintela wrote:
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintela
---
QMP/qmp-events.txt | 50 ++
monitor.c | 12
monitor.h |
On 05/25/2010 08:21 AM, Andre Przywara wrote:
What's the benefit of exposing this information to the guest?
That is mostly to propagate the cache size and organization parameters
to the guest:
>> +/* safe CPUID leafs to propagate to guest if -cpu host is specified
>> + * Intel defined leafs:
On 05/25/2010 05:09 PM, Kevin Wolf wrote:
The first part of your argument may be true, but the second isn't. No
user can run upstream qemu.git. It's not tested or supported, and has
no backwards compatibility guarantees.
The second part was basically meant to say "developers don't coun
On 05/25/2010 05:03 PM, Anthony Liguori wrote:
On 05/25/2010 08:55 AM, Avi Kivity wrote:
On 05/25/2010 04:53 PM, Kevin Wolf wrote:
I'm still not convinced that we need either. I share Christoph's
concern
that we would make our life harder for almost no gain. It's probably a
very small group
On 05/25/2010 05:05 PM, Anthony Liguori wrote:
On 05/25/2010 09:01 AM, Avi Kivity wrote:
On 05/25/2010 04:55 PM, Anthony Liguori wrote:
On 05/25/2010 08:38 AM, Avi Kivity wrote:
On 05/25/2010 04:35 PM, Anthony Liguori wrote:
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism
On 05/25/2010 10:00 AM, Avi Kivity wrote:
The latter. Why is it less important? If you don't inherit the
memory, you can't access it.
You can also pass /dev/shm fd's via SCM_RIGHTs to establish shared
memory segments dynamically.
Doesn't work for anonymous memory.
What's wrong with /dev/
Generic Asynchronous task offloading
- keep vcpu thread from blocking
- generic approach is useful, comes down to specifics
- e.g. what is done in worker threads, how locking is handled
- offload blocking work to worker threads
- need to make device model reentrant
- can be simple w/ lock per
Signed-off-by: Juan Quintela
---
migration-exec.c |3 ++-
migration-fd.c |1 +
migration-tcp.c |2 ++
migration-unix.c |2 ++
migration.c |5 +
5 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/migration-exec.c b/migration-exec.c
index 07af11a..ebc92
At Mon, 24 May 2010 14:16:32 -0500,
Anthony Liguori wrote:
>
> On 05/24/2010 06:56 AM, Avi Kivity wrote:
> > On 05/24/2010 02:42 PM, MORITA Kazutaka wrote:
> >>
> >>> The server would be local and talk over a unix domain socket, perhaps
> >>> anonymous.
> >>>
> >>> nbd has other issues though, suc
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintela
---
QMP/qmp-events.txt | 50 ++
monitor.c | 12
monitor.h |4
3 files changed, 66 insertions(+), 0
Additional Info:
1) If I use rtl8139 instead of e1000 NIC driver. The VM freezes at 100% CPU
after migration
2) Ubuntu Lucid LTS 64-bit Server is also affected and shows same symtomps
--
e1000 irq problems after live migration with qemu-kvm 0.12.4
https://bugs.launchpad.net/bugs/585113
You rec
Am 25.05.2010 15:25, schrieb Avi Kivity:
> On 05/25/2010 04:17 PM, Anthony Liguori wrote:
>> On 05/25/2010 04:14 AM, Avi Kivity wrote:
>>> On 05/24/2010 10:38 PM, Anthony Liguori wrote:
> - Building a plugin API seems a bit simpler to me, although I'm to
> sure if I'd get the
>
On 05/25/2010 04:54 PM, Anthony Liguori wrote:
On 05/25/2010 08:36 AM, Avi Kivity wrote:
We'd need a kernel-level generic snapshot API for this eventually.
or (2) implement BUSE to complement FUSE and CUSE to enable proper
userspace block devices.
Likely slow due do lots of copying. Also n
Signed-off-by: Juan Quintela
---
migration.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/migration.c b/migration.c
index c388902..32470d5 100644
--- a/migration.c
+++ b/migration.c
@@ -60,10 +60,13 @@ int qemu_start_incoming_migration(const char *uri)
void proces
Signed-off-by: Juan Quintela
---
migration.c | 16 ++--
migration.h |2 +-
vl.c|7 ++-
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/migration.c b/migration.c
index 05f6cc5..9c1d4b6 100644
--- a/migration.c
+++ b/migration.c
@@ -36,22 +36,26 @@
v2:
- Address pbonzini and mst changes
(error messages and doc fixes)
v1:
This series does:
- exit incoming migration on failure. For exec/fd migrations, once
there was a failure, there was nothing useful to do. And for tcp
migration, not exiting created interesting bugs when trying to
Signed-off-by: Juan Quintela
---
migration-exec.c | 14 +-
migration-fd.c | 14 +-
migration-tcp.c | 15 ++-
migration-unix.c | 15 ++-
migration.c | 13 +
migration.h |2 ++
6 files changed, 21 insertions(+),
On 05/25/2010 08:25 AM, Avi Kivity wrote:
On 05/25/2010 04:17 PM, Anthony Liguori wrote:
On 05/25/2010 04:14 AM, Avi Kivity wrote:
On 05/24/2010 10:38 PM, Anthony Liguori wrote:
- Building a plugin API seems a bit simpler to me, although I'm to
sure if I'd get the
idea correctly:
The b
On 05/25/2010 09:01 AM, Avi Kivity wrote:
On 05/25/2010 04:55 PM, Anthony Liguori wrote:
On 05/25/2010 08:38 AM, Avi Kivity wrote:
On 05/25/2010 04:35 PM, Anthony Liguori wrote:
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism has the advantage of being more robust
in the
On 05/25/2010 08:38 AM, Avi Kivity wrote:
On 05/25/2010 04:35 PM, Anthony Liguori wrote:
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism has the advantage of being more robust
in the face of poorly written block backends so if it's possible to
make it perform as well as a
On 05/25/2010 08:57 AM, Avi Kivity wrote:
On 05/25/2010 04:54 PM, Anthony Liguori wrote:
On 05/25/2010 08:36 AM, Avi Kivity wrote:
We'd need a kernel-level generic snapshot API for this eventually.
or (2) implement BUSE to complement FUSE and CUSE to enable proper
userspace block devices.
On 05/25/2010 04:31 PM, Anthony Liguori wrote:
On 05/25/2010 08:19 AM, Avi Kivity wrote:
On 05/25/2010 04:03 PM, Anthony Liguori wrote:
I don't think that qdev device names and paths are something we
have to worry much about changing over time since they reflect
logical bus layout. They sho
On 05/25/2010 04:55 PM, Anthony Liguori wrote:
On 05/25/2010 08:38 AM, Avi Kivity wrote:
On 05/25/2010 04:35 PM, Anthony Liguori wrote:
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism has the advantage of being more robust
in the face of poorly written block backends so if
On Tue, May 25, 2010 at 2:52 PM, Avi Kivity wrote:
> Hm. Perhaps we can convert %{type} to %p for backends which don't support
> it, and to whatever format they do support for those that do.
True.
Stefan
Am 25.05.2010 15:55, schrieb Avi Kivity:
> On 05/25/2010 04:53 PM, Kevin Wolf wrote:
>>
>> I'm still not convinced that we need either. I share Christoph's concern
>> that we would make our life harder for almost no gain. It's probably a
>> very small group of users (if it exists at all) that wants
On 05/25/2010 08:36 AM, Avi Kivity wrote:
We'd need a kernel-level generic snapshot API for this eventually.
or (2) implement BUSE to complement FUSE and CUSE to enable proper
userspace block devices.
Likely slow due do lots of copying. Also needs a snapshot API.
The kernel could use spli
On 05/25/2010 08:55 AM, Avi Kivity wrote:
On 05/25/2010 04:53 PM, Kevin Wolf wrote:
I'm still not convinced that we need either. I share Christoph's concern
that we would make our life harder for almost no gain. It's probably a
very small group of users (if it exists at all) that wants to add n
On 05/25/2010 04:27 PM, Stefan Hajnoczi wrote:
On Tue, May 25, 2010 at 1:04 PM, Avi Kivity wrote:
Those %ps are more or less useless. We need better ways of identifying
them.
You're right, the vq pointer is useless in isolation. We don't know
which virtio device or which virtqueue
On Tue, May 25, 2010 at 1:04 PM, Avi Kivity wrote:
> Those %ps are more or less useless. We need better ways of identifying
> them.
You're right, the vq pointer is useless in isolation. We don't know
which virtio device or which virtqueue number.
With the full context of a trace it would be po
Am 24.05.2010 08:34, schrieb MORITA Kazutaka:
> At Fri, 21 May 2010 18:57:36 +0200,
> Kevin Wolf wrote:
>>
>> Am 20.05.2010 07:36, schrieb MORITA Kazutaka:
>>> +
>>> +/*
>>> + * Append an option list (list) to an option list (dest).
>>> + *
>>> + * If dest is NULL, a new copy of list is created.
>>
On 05/25/2010 04:53 PM, Kevin Wolf wrote:
I'm still not convinced that we need either. I share Christoph's concern
that we would make our life harder for almost no gain. It's probably a
very small group of users (if it exists at all) that wants to add new
block drivers themselves, but at the sam
On 05/25/2010 08:19 AM, Avi Kivity wrote:
On 05/25/2010 04:03 PM, Anthony Liguori wrote:
I don't think that qdev device names and paths are something we
have to worry much about changing over time since they reflect
logical bus layout. They should remain static provided the devices
remain s
Am 25.05.2010 15:25, schrieb Anthony Liguori:
> On 05/25/2010 06:25 AM, Avi Kivity wrote:
>> On 05/25/2010 02:02 PM, Kevin Wolf wrote:
>>>
> So could we not standardize a protocol for this that both sheepdog and
> ceph could implement?
The protocol already exists, nbd. It doesn't
On 05/25/2010 04:26 PM, Anthony Liguori wrote:
On 05/25/2010 08:21 AM, Andre Przywara wrote:
What's the benefit of exposing this information to the guest?
That is mostly to propagate the cache size and organization
parameters to the guest:
>> +/* safe CPUID leafs to propagate to guest if -cp
On 05/25/2010 04:25 PM, Anthony Liguori wrote:
Currently if someone wants to add a new block format, they have to
upstream it and wait for a new qemu to be released. With a plugin
API, they can add a new block format to an existing, supported qemu.
Whether we have a plugin or protocol based
On 05/25/2010 04:35 PM, Anthony Liguori wrote:
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism has the advantage of being more robust in
the face of poorly written block backends so if it's possible to
make it perform as well as a plugin, it's a preferable approach.
May b
On 05/25/2010 08:31 AM, Avi Kivity wrote:
A protocol based mechanism has the advantage of being more robust in
the face of poorly written block backends so if it's possible to make
it perform as well as a plugin, it's a preferable approach.
May be hard due to difficulty of exposing guest memor
1 - 100 of 191 matches
Mail list logo
