On Friday 27 November 2009 05:17:32 Vincent Sanders wrote:
I appear to be unable to take a hint, your silence on this patch in
the past probably ought to have been a clue. however this will be the
last time I bother to try and get anything merged so you wont have to
be disturbed again.
The
Alexander Graf wrote:
For the technical reason I hope Carsten can provide some insight.
As for the implementation reason - S390 KVM (the kernel part) doesn't do
memslots properly :-).
I'm sorry, I cannot comment on that :-(.
On Mon, Nov 30, 2009 at 09:34:58PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Wed, Nov 25, 2009 at
Alexander Graf ag...@suse.de writes:
Currently we have this stupid role of disallowing:
if (r)
break;
By disallowing this we clutter the code, making it less readable without
buying us anything. In fact, nobody actually sticks to this because it'd show
just how much bad taste the
Alexander Graf wrote:
I don't know what psw.mask represent, but it may be wrong. It should be
a way to identify which TB can be reused, that is they have been
generated in the same CPU mode.
psw.mask is rougly the same as RFLAGS, cr0 and cr4 on x86_64 combined. So IMHO
it looked like a pretty
Kevin Wolf kw...@redhat.com writes:
Currently qcow2 unnecessarily rounds up the length of the backing format
string
to the next multiple of 8. At the same time, the array in BlockDriverState can
only hold 15 characters, so in effect backing formats with 9 characters or
more
don't work
Gerd Hoffmann kra...@redhat.com writes:
The patch decuples the -chardev switch and the actual chardev
initialization. Without this patch qemu ignores chardev entries
coming via -readconfig.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Makes sense to me.
On 01.12.2009, at 10:46, Carsten Otte wrote:
Alexander Graf wrote:
I don't know what psw.mask represent, but it may be wrong. It should be
a way to identify which TB can be reused, that is they have been
generated in the same CPU mode.
psw.mask is rougly the same as RFLAGS, cr0 and cr4 on
On Thu, Nov 26, 2009 at 10:58:50PM -0200, Luiz Capitulino wrote:
Hi,
This series has a number of improvements over v0 and is a serious
candidate for inclusion.
Something I'd like to make clear is that QMP is still unstable:
some commands output are being fixed and most of the error
Hi,
Could someone with commit rights please stand up to feel responsible
for PPC?
Usually, when I send a patch to qemu-devel, I know who to address to
increase chances of it getting committed. For kvm/vnc/block I just CC
Anthony, for Audio I just CC malc, etc.
There are some subsystems
On 11/30/2009 07:30 PM, Jan Kiszka wrote:
No. But what's wrong with on_vcpu?
intrinsically racy. signal passing slow down things, etc.
That said, as I've stated many times: I don't believe there's anything
fundamentally wrong with on_vcpu. But we might get benefits from a re-design
Avi Kivity wrote:
On 11/30/2009 07:30 PM, Jan Kiszka wrote:
No. But what's wrong with on_vcpu?
intrinsically racy. signal passing slow down things, etc.
That said, as I've stated many times: I don't believe there's anything
fundamentally wrong with on_vcpu. But we might get
Glauber Costa wrote:
Hi guys,
This is an early version of smp support in kvm that kinda works.
It has some known problems that I am still tracking. For example,
it does not reset very well. Also, initialization is a bit slow,
probably because of the number of remote ioctl calls involved.
On Tue, Dec 1, 2009 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
Avi Kivity wrote:
On 11/30/2009 07:30 PM, Jan Kiszka wrote:
No. But what's wrong with on_vcpu?
intrinsically racy. signal passing slow down things, etc.
That said, as I've stated many times: I don't believe there's
Glauber Costa wrote:
On Tue, Dec 1, 2009 at 10:17 AM, Jan Kiszka jan.kis...@siemens.com wrote:
Avi Kivity wrote:
On 11/30/2009 07:30 PM, Jan Kiszka wrote:
No. But what's wrong with on_vcpu?
intrinsically racy. signal passing slow down things, etc.
That said, as I've stated many times: I
diff --git a/qemu-malloc.c b/qemu-malloc.c
index 295d185..aeeb78b 100644
--- a/qemu-malloc.c
+++ b/qemu-malloc.c
@@ -44,22 +44,12 @@ void qemu_free(void *ptr)
void *qemu_malloc(size_t size)
{
-if (!size) {
-abort();
-}
-return oom_check(malloc(size));
+return
This is a repost of the -smp series. Note that it depends on irqchip-in-kernel,
that is already in staging. Also, you'll have to enable the io-thread, for the
time
being.
From the last version, main change is that I am not calling queue_work
automatically
from vcpu ioctls. queue_work is only
Since we'll have multiple cpu threads, at least for kvm, we need a way to store
and retrieve the CPUState associated with the current execution thread.
For the I/O thread, this will be NULL.
I am using pthread functions for that, for portability, but we could as well
use __thread keyword.
When we have irqchip in kernel, halted state is kernel
business. So don't initialize it in our code.
Signed-off-by: Glauber Costa glom...@redhat.com
---
hw/apic-kvm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/apic-kvm.c b/hw/apic-kvm.c
index 089fa45..e5a0bfc
If we are using in-kernel irqchip, halted state belongs in the kernel.
So everytime we grab kernel's idea of mpstate, we also need to propagate
halted state to userspace.
Signed-off-by: Glauber Costa glom...@redhat.com
---
target-i386/kvm.c |5 +
1 files changed, 5 insertions(+), 0
This function is similar to qemu-kvm's on_vcpu mechanism. Totally synchronous,
and guarantees that a given function will be executed at the specified vcpu.
This patch also convert usage within the breakpoints system
Signed-off-by: Glauber Costa glom...@redhat.com
---
cpu-all.h |3 ++
This fix a bug with -smp in kvm. Since we have updated apic_base,
we also have to tell kernel about it. So instead of just updating
mp_state, update every regs.
It is mandatory that this happens synchronously, without waiting for
the next vcpu run. Otherwise, if we are migrating, or initializing
This have already been identified in qemu-kvm. We have to synchronously
tell the kernel about the APIC state. Otherwise, other cpus can see
bogus state for this lapic.
Signed-off-by: Glauber Costa glom...@redhat.com
---
hw/apic-kvm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
All reset functions are called from the same place, and this was a leftover
Signed-off-by: Glauber Costa glom...@redhat.com
---
kvm-all.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 318a4e6..ecd1102 100644
--- a/kvm-all.c
+++ b/kvm-all.c
It is much faster than pthread_{g,s}et_specific.
Signed-off-by: Glauber Costa glom...@redhat.com
---
configure | 17 +
vl.c | 16
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index dca5a43..ce7bcc4 100755
---
On Tue, 1 Dec 2009 11:38:52 +
Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Nov 26, 2009 at 10:58:50PM -0200, Luiz Capitulino wrote:
Hi,
This series has a number of improvements over v0 and is a serious
candidate for inclusion.
Something I'd like to make clear is
On 12/01/09 13:40, Gerd Hoffmann wrote:
+ return oom_check(malloc(size ? size : 1));
void *qemu_realloc(void *ptr, size_t size)
{
+ return oom_check(realloc(ptr, size ? size : 1));
qemu_realloc(qemu_malloc(0), 42);
should better work correctly ...
Oops, scratch that.
return malloc(size
You might want to have a 'static uint8_t zero_length_malloc[0]' and
return that instead of the magic cookie '1'. Makes the code more
readable IMHO and you'll also have symbol in gdb when debugging qemu.
Having multiple malloc return the same pointer sounds like a really bad idea.
Paul
Gerd Hoffmann kra...@redhat.com writes:
diff --git a/qemu-malloc.c b/qemu-malloc.c
index 295d185..aeeb78b 100644
--- a/qemu-malloc.c
+++ b/qemu-malloc.c
@@ -44,22 +44,12 @@ void qemu_free(void *ptr)
void *qemu_malloc(size_t size)
{
-if (!size) {
-abort();
-}
-
Juan Quintela wrote:
Jan Kiszka jan.kis...@siemens.com wrote:
Juan Quintela wrote:
Pierre Riteau pierre.rit...@irisa.fr wrote:
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination
On Tue, Dec 01, 2009 at 12:57:27PM +, Paul Brook wrote:
You might want to have a 'static uint8_t zero_length_malloc[0]' and
return that instead of the magic cookie '1'. Makes the code more
readable IMHO and you'll also have symbol in gdb when debugging qemu.
Having multiple malloc
Glauber Costa glom...@redhat.com writes:
On Tue, Dec 01, 2009 at 12:57:27PM +, Paul Brook wrote:
You might want to have a 'static uint8_t zero_length_malloc[0]' and
return that instead of the magic cookie '1'. Makes the code more
readable IMHO and you'll also have symbol in gdb when
The effect of this patch with current block migration is that its stage
2, ie. the first full walk-through of the block devices will be
performed completely before RAM migration starts. This ensures that
continuously changing RAM pages are not re-synchronized all the time
while block migration is
Inject progress report in percentage into the block live stream. This
can be read out and displayed easily on restore.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Changes in v2:
- Print banner only if there is really some block device to restore
block-migration.c | 30
On Tuesday 01 December 2009, Glauber Costa wrote:
On Tue, Dec 01, 2009 at 12:57:27PM +, Paul Brook wrote:
You might want to have a 'static uint8_t zero_length_malloc[0]' and
return that instead of the magic cookie '1'. Makes the code more
readable IMHO and you'll also have symbol in
The opts id is always allocated via qemu_strdup, so it need not be
const, but it has to be released on opts deletion.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-option.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index
On 12/01/2009 02:40 PM, Gerd Hoffmann wrote:
Even more advanced: Make zero_length_malloc page-sized and
page-aligned, then munmap int, so dereferencing it actually traps.
That will cause vma fragmentation. Since we don't trap malloc(n)[n] for
n 0, we may as well not trap it for n = 0.
Hello Ian,
Since you did not inline your source I will paste in a chunk:
@@ -2030,10 +2036,18 @@ static void tcp_chr_read(void *opaque)
if (s-listen_fd = 0) {
qemu_set_fd_handler(s-listen_fd, tcp_chr_accept, NULL,
chr);
}
-qemu_set_fd_handler(s-fd, NULL,
On 12/01/09 15:08, Markus Armbruster wrote:
For what it's worth, it violates the spec for malloc(). For zero-sized
allocations, we may either return a null pointer (but we already decided
we don't want to), or an object different from any other object alive.
Which clearly rules out the fixed
On 12/01/09 15:34, Avi Kivity wrote:
On 12/01/2009 02:40 PM, Gerd Hoffmann wrote:
Even more advanced: Make zero_length_malloc page-sized and
page-aligned, then munmap int, so dereferencing it actually traps.
That will cause vma fragmentation.
I was thinking about a single unmapped page,
Excerpts from Markus Armbruster's message of Mon Nov 30 11:55:34 -0200 2009:
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's malloc() friends. Revert that, but take care never to
return a null pointer, like malloc() friends may do (it's
implementation
Kevin Wolf wrote:
We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
descriptors that don't need to be passed to children to stop this
misbehaviour.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/raw-posix.c |2 +-
gdbstub.c |6 +++
Here is a collection of minor pci related fixes and cleanupsthat has
accumulated in my tree. I think some of these make sense for 0.11 as
well, I will follow up separately.
The following changes since commit 3098b9fde97a224e803048c83bebeea176966358:
Aurelien Jarno (1):
Revert vga: do
Glauber Costa wrote:
This patch provides the file apic-kvm.c, which implements a schim over
the kvm in-kernel APIC.
Signed-off-by: Glauber Costa glom...@redhat.com
---
Makefile.target |2 +-
hw/apic-kvm.c | 157
+
hw/pc.c
Glauber Costa wrote:
This patch provides the file i8259-kvm.c, which implements a schim over
the kvm in-kernel PIC.
Signed-off-by: Glauber Costa glom...@redhat.com
---
Makefile.target |2 +-
hw/i8259-kvm.c | 112
+++
hw/pc.c
On 1 déc. 2009, at 15:20, Jan Kiszka wrote:
Inject progress report in percentage into the block live stream. This
can be read out and displayed easily on restore.
I guess that this patch only reports percentage for the initial bulk copy of
the image.
I haven't tested this scenario, but the
On S390X:
/suse/agraf/work/kvm-s390/qemu.works/kvm-all.c: In function ‘kvm_set_irq’:
/suse/agraf/work/kvm-s390/qemu.works/kvm-all.c:425: error:
‘KVM_IRQ_LINE_STATUS’ undeclared (first use in this function)
/suse/agraf/work/kvm-s390/qemu.works/kvm-all.c:425: error: (Each
undeclared
Pierre Riteau wrote:
On 1 déc. 2009, at 15:20, Jan Kiszka wrote:
Inject progress report in percentage into the block live stream. This
can be read out and displayed easily on restore.
I guess that this patch only reports percentage for the initial bulk copy of
the image.
I haven't
Krumme, Chris wrote:
Hello Ian,
Hi!
Should you be introducing a while sleep loop into Qemu here?
I would think you should be returning 'no data', maybe after trying
once.
Indeed.
I could have sworn I tried that. Too much crack, will re-do.
Hello All,
I have a question about read permissions of TBL SPR for all ppc processors:
I have discovered that my application, compiled by WindRiver diab compiler
and running in vxworks OS on ppc405 architecture bumps into exception
generated when trying to read TBL or TBU registers:
program
2009/12/1 Carsten Otte carst...@de.ibm.com:
Alexander Graf wrote:
I don't know what psw.mask represent, but it may be wrong. It should be
a way to identify which TB can be reused, that is they have been
generated in the same CPU mode.
psw.mask is rougly the same as RFLAGS, cr0 and cr4 on
Alexander Graf wrote:
Hi,
Could someone with commit rights please stand up to feel responsible
for PPC?
Usually, when I send a patch to qemu-devel, I know who to address to
increase chances of it getting committed. For kvm/vnc/block I just CC
Anthony, for Audio I just CC malc, etc.
There
Krumme, Chris wrote:
Hello Ian,
Since you did not inline your source I will paste in a chunk:
@@ -2030,10 +2036,18 @@ static void tcp_chr_read(void *opaque)
if (s-listen_fd = 0) {
qemu_set_fd_handler(s-listen_fd, tcp_chr_accept, NULL,
chr);
}
-
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
This may partly or fully explain the e1000 issue Pierre reported first.
However, there are more bugs in the current migration code, e.g. in
qemu_fseek when used with streams, it still doesn't work properly here.
Need a break...
hw/hw.h |2
On Tue, Dec 1, 2009 at 6:51 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Alexander Graf wrote:
Hi,
Could someone with commit rights please stand up to feel responsible for
PPC?
Usually, when I send a patch to qemu-devel, I know who to address to
increase chances of it getting
Jan Kiszka jan.kis...@siemens.com wrote:
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
This may partly or fully explain the e1000 issue Pierre reported first.
However, there are more bugs in the current migration code, e.g. in
qemu_fseek when used with streams, it still doesn't work
From: qemu-devel-bounces+chris.krumme=windriver@nongnu.org
[mailto:qemu-devel-bounces+chris.krumme=windriver@nongnu.org] On
Behalf Of Dima Ilyevsky
Sent: Tuesday, December 01, 2009 12:33 PM
To: qemu-devel@nongnu.org
Subject:
This iteration addresses all of the comments from the last round. Thanks to
everyone for their careful reviews and helpful comments. The most significant
change in this version is my use of the QObject API, so a concentrated review
in that area would be most appreciated. I am hoping to target
Blue Swirl wrote:
Of course, my main unclear subsystems are PPC and S390.
I'd recommend the following committers:
PPC: Blue Swirl
S390: Aurelien
If you have other subsystems you feel uncertain on responsibilities,
please add them to the list incl. committer recommendation.
PPC is
On 01.12.2009, at 19:51, Anthony Liguori wrote:
Alexander Graf wrote:
Hi,
Could someone with commit rights please stand up to feel responsible for PPC?
Usually, when I send a patch to qemu-devel, I know who to address to
increase chances of it getting committed. For kvm/vnc/block I
On 01.12.2009, at 19:33, Dima Ilyevsky wrote:
Hello All,
I have a question about read permissions of TBL SPR for all ppc processors:
I have discovered that my application, compiled by WindRiver diab compiler
and running in vxworks OS on ppc405 architecture bumps into exception
generated
On Wed, 2 Dec 2009, Alexander Graf wrote:
On 01.12.2009, at 19:33, Dima Ilyevsky wrote:
Hello All,
I have a question about read permissions of TBL SPR for all ppc processors:
I have discovered that my application, compiled by WindRiver diab compiler
and running in vxworks OS on
Seeking on vmstate save/load does not work if the underlying file is a
stream. We could try to make all QEMUFile* forward-seek-aware, but first
attempts in this direction indicated that it's saner to convert the few
qemu_fseek-on-vmstates users to plain reads/writes.
This fixes various subtle
While most of the ARMv5 instructions are backward compatible with ARMv4, there
are few important differences. Most notably the stack pop and load instructions
ignore the lowest bit, which is used by ARMv5 to switch to Thumb mode. A
base-updated data-abort model is used on ARM7TDMI, CP15
Blue Swirl wrote:
The translation block (TB) refers to a block of host instructions,
translated from some block of target instructions under some
assumptions. The assumptions used when translating (for example, user
vs supervisor mode in the CPU state) are recorded to TB flags. If the
CPU state
65 matches
Mail list logo
