The QOM framework will attempt the recreate a classes interface list from
scratch for each class. This means that a child class should zero out the
list of interfaces when cloned from the parent class.
Currently the list is memcpy()d from the parent to the child. As the interface
list is just a po
My email address is changing from:
er...@mips.com
to
eric.john...@imgtec.com
I've already subscribed the new email address to the list. Emails to the
previous address will forward to my new address for an unspecified amount of
time.
The MIPS Technologies website (http://www.mips.com) announces
num_interfaces only tells you how many interfaces the concrete child class has
(as defined in the TypeInfo). This means if you have a child class which defines
no interfaces of its own, but its parent has interfaces you cannot cast to those
parent interfaces.
Fixed by removing the guard altogether
I recently tried to create a new QOM class which inherited from a class which
defined interfaces. This has so far gone untested and my little experiment
exposed two bugs in the QOM interface system. Please see patches for
corrections. Im pretty convinced about patch 2, patch 1 less so and could
> Am 29.01.2013 10:23, schrieb Guan Xuetao:
>>> -���浠跺��浠�-
>>> ���浠朵��: Andreas F盲rber [mailto:afaer...@suse.de]
>>> 堕��: Sunday, January 27, 2013 21:32
>>> ��朵欢浜�: qemu-devel@nongnu.org
>>> ��: Andreas F盲rber; Guan Xuetao (maintainer:UniCore32)
>>> 涓婚��: [RFC 19/19] target-uni
This gives an awful silent failure when it doesn't work. Assert against link
creation failure.
Signed-off-by: Peter Crosthwaite
---
hw/xilinx_axienet.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/xilinx_axienet.c b/hw/xilinx_axienet.c
index 34e344c..e5d9251 100
>
> As indicated above, this patch has a bug, sorry. I will send a v2.
> Forking in linux-user will be broken (cpu_copy()), everything else
> should work though, no?
>
> Can you please test qemu.git master and confirm that it is not broken
> without this patch?
>
> I do not have any unicore32 image
On (Wed) 30 Jan 2013 [08:38:50], Anthony Liguori wrote:
> Amit Shah writes:
>
> > Hi Anthony,
> >
> > I did some basic testing of the char flow control patches from your
> > char-flow.2 branch. With the following patch applied, things seem to
> > be working fine. I tested the isa-serial and vir
- Original Message -
> From: "Eric Blake"
> To: "Miroslav Rezanina"
> Cc: qemu-devel@nongnu.org, kw...@redhat.com, pbonz...@redhat.com,
> stefa...@redhat.com
> Sent: Friday, February 8, 2013 8:19:45 PM
> Subject: Re: [PATCH 3/4] This patch adds new qemu-img subcommand that
> compares
Hi Eric,
- Original Message -
> From: "Eric Blake"
> To: "Miroslav Rezanina"
> Cc: qemu-devel@nongnu.org, kw...@redhat.com, pbonz...@redhat.com,
> stefa...@redhat.com
> Sent: Friday, February 8, 2013 6:07:35 PM
> Subject: Re: [PATCH 2/4] qemu-img: Add "Quiet mode" option
>
> On 02/08/20
Currently the spapr-vlan device does not supply a cleanup call for its
NetClientInfo structure. With current qemu versions, that leads to a SEGV
on exit, when net_cleanup() attempts to call the cleanup handlers on all
net clients.
Signed-off-by: David Gibson
---
hw/spapr_llan.c |8
The PowerPC 620 was the very first 64-bit PowerPC implementation, but
hardly anyone ever actually used the chips. qemu notionally supports the
620, but since we don't actually have code to implement the segment table,
the support is broken (quite likely in other ways too).
This partch, therefore,
Hello Stefan,
As you can read dedup keep me awake at night.
I still think that there is a need for a deduplication implementation
that would perform nearly as fast as regular qcow2.
I though about this: http://en.wikipedia.org/wiki/Normal_distribution.
Not all block are equals for deduplicatio
On Fri, 8 Feb 2013 16:13:02 -0200
Eduardo Habkost wrote:
> On Fri, Feb 08, 2013 at 05:54:50PM +0100, Andreas Färber wrote:
> > Am 08.02.2013 15:52, schrieb Eduardo Habkost:
> > > On Fri, Feb 08, 2013 at 01:58:42PM +0100, Igor Mammedov wrote:
> > >> On Fri, 08 Feb 2013 12:16:17 +0100
> > >> Andrea
That's great, thanks
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1120383
Title:
incremental live block migration of qemu 1.3.1 doesn't work
Status in QEMU:
New
Bug description:
We tested qe
On Thu, Feb 07, 2013 at 09:28:20AM -0200, Erlon Cruz wrote:
> From: Erlon Cruz
>
> This h_call is useful for DLPAR in future amongst other things. Given an index
> it fetches the corresponding PTE stored in the htab.
Nice. It would be good to add in this little bit of PAPR compliance.
Couple o
The .save_live_iterate() function returns 0 to continue iterating or 1
to stop iterating.
Since 16310a3cca7320edb9341c976f7819de0a8c27e0 it only ever returns 0,
leading to an infinite loop.
Return 1 if we have finished sending dirty blocks.
Signed-off-by: Stefan Hajnoczi
---
block-migration.c
Commit 43be3a25c931a7f61a76fbfc9d35584cbfc5fb58 changed the
blk_mig_save_dirty_block() return code handling. The function's doc
comment says:
/* return value:
* 0: too much data for max_downtime
* 1: few enough data for max_downtime
*/
Because of the 1 return value, callers must check
Show the actual flags value and include "block migration" in the error
message so it's clear where the error is coming from.
Signed-off-by: Stefan Hajnoczi
---
block-migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block-migration.c b/block-migration.c
index 9ac7de
Block migration is currently broken. This series fixes it.
Patch 1 - improve "Unknown flags" error message
Patch 2 - the "Unknown flags" error means the source and destination QEMUs are
not in sync. The destination expects a block migration message but finds an
unexpected message. This is beca
Signed-off-by: Hervé Poussineau
---
hw/ide/core.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 3743dc3..f0ab1a8 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1394,8 +1394,10 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
This variable has been removed 5 years ago in
970ac5a3082428dca91171f270dcd95d6f4b2636.
Signed-off-by: Hervé Poussineau
---
include/sysemu/sysemu.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 1d9599e..ae49088 100644
--- a/include
On Sun, Feb 10, 2013 at 3:48 AM, Reno Gan wrote:
> Another thing i want to mention about live block migration, though i
> don't know if this is really an issue of qemu or downstream libvirt.
>
> When I was testing live migration of qemu-kvm-1.2.0 for long run, i
> found a problem that block data a
Hi,
tried to reproduce... but wasn't able to...
Stefan
Am 08.02.2013 11:43, schrieb Paolo Bonzini:
Il 08/02/2013 11:29, Stefan Priebe - Profihost AG ha scritto:
Hello list,
while testing current git master
(ecd8d4715ea33aa2c146a5047bacb031e86af599) i've seen a VM endless
looping - the monitor
Signed-off-by: Richard Henderson
---
linux-user/signal.c | 58 -
1 file changed, 58 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 67c2311..b2f1d29 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2438,6
Signed-off-by: Richard Henderson
---
target-mips/translate.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 3b77b53..b3b8dc6 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -15972,6 +15972,14 @@ void
Signed-off-by: Richard Henderson
---
configure | 4
1 file changed, 4 insertions(+)
diff --git a/configure b/configure
index 8789324..f36acdd 100755
--- a/configure
+++ b/configure
@@ -978,6 +978,10 @@ microblaze-linux-user \
microblazeel-linux-user \
mips-linux-user \
mipsel-linux-user
Signed-off-by: Richard Henderson
---
linux-user/signal.c | 157 +--
target-mips/cpu.h| 3 +
target-mips/dsp_helper.c | 16 -
3 files changed, 58 insertions(+), 118 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
Signed-off-by: Richard Henderson
---
linux-user/main.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 3df8aa2..3a3be70 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -1783,8 +1783,8 @@ void cpu_
Signed-off-by: Richard Henderson
---
linux-user/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
I don't actually recall why this patch was in my old tree. It might
just have been that I wanted a mips64r2 part for testing and didn't
want to keep specifying -cpu on the command-lin
Signed-off-by: Richard Henderson
---
linux-user/main.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 8c4dffd..25491ca 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -46,10 +46,10 @@ int gdbstub_port;
envlis
COP1X refers to the availability of indexed memory operations,
not whether the FPU has 64-bit registers.
Signed-off-by: Richard Henderson
---
target-mips/translate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index b3b8
Signed-off-by: Richard Henderson
---
linux-user/signal.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index b2f1d29..7da676f 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2438,8 +2438,
Peter's recent userland syscall testing has encouraged me to clean
up and re-submit some ages-old patches to enable userland testing
of the other mips abis.
Please review.
r~
Richard Henderson (10):
mips-linux-user: Delete n32 and n64 signal stubs
mips-linux-user: Share o32 code for n32 an
On Fri, Feb 08, 2013 at 10:18:19PM +1100, Vadim Rozenfeld wrote:
> On Thu, 2013-02-07 at 14:33 +0100, Laszlo Ersek wrote:
> > Apologies in advance for asking a possibly exorbitantly lame question...
> >
> > On 02/06/13 10:47, Vadim Rozenfeld wrote:
> > > On Tue, 2013-02-05 at 13:58 +0200, Michael
On Sat, Feb 09, 2013 at 02:56:01PM -0200, Lucas Meneghel Rodrigues wrote:
> Hey Gleb, Marcelo:
>
> I was looking at the sanity jobs for qemu.git and found this error
> that happened during RHEL 6.3 guest reboot test:
>
RIP==RAX. Probably emulation gone wrong. Can you verify if it
reproducible?
P
On Sun, Feb 10, 2013 at 6:42 AM, Michael Tokarev wrote:
> 09.02.2013 23:01, Blue Swirl wrote:
>>
>> Check if xsltproc and Sparc32, Sparc64 and PPC compilers
>> are available. If found, rebuild OpenBIOS ROMs from submodule.
>>
>> Signed-off-by: Blue Swirl
>> ---
>> A patch to OpenBIOS is also need
37 matches
Mail list logo