For now, just some removal of dead code (empty inline functions).
Paolo Bonzini (3):
remove dead code from target-i386/exec.h
kill regs_to_env and env_to_regs
fix wrong indentation
cpu-exec.c | 13 +--
target-alpha/exec.h |8 --
target-arm/exec.h
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-exec.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index a426db9..2f119a9 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -588,11 +588,9 @@ int cpu_exec(CPUState *env1)
/*
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-exec.c |9 -
target-alpha/exec.h |8
target-arm/exec.h|8
target-cris/exec.h |8
target-i386/exec.h |8
target-m68k/exec.h |8
On Thu, Jan 14, 2010 at 02:59:51PM -0800, Richard Henderson wrote:
The existing P_REXB internal opcode flag unconditionally emits
the REX prefix. Technically it's not needed if the register in
question is %al, %bl, %cl, %dl.
Eliding the prefix requires splitting the P_REXB flag into two,
The management of env-current_tb is quite complicated. In particular,
a while loop that has it as a test condition is actually executed just
once, and it is cleared long after it has ceased being meaningful.
This patch set straightens things a bit. Patch 1 clears env-current_tb
when it is not
By virtue of the previous patch env-current_tb will always be NULL at
the top of cpu_exec's outermost for loop, and at the end of the innermost
while loop.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-exec.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git
There are three paths from the innermost while loop of cpu_exec
to the top of the outermost for loop. Two do not reset
env-current_tb. Fix this.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-exec.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/cpu-exec.c
The while loop will be executed exactly 0 or 1 times, depending on
env-exit_request.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-exec.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index d974141..f00151f 100644
---
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-exec.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index f00151f..0256edf 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -22,8 +22,6 @@
#include tcg.h
#include kvm.h
-#include
These are unused since edea5f0 (no need to define global registers in
cpu-exec.c, 2008-05-10).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
target-i386/exec.h | 48
1 files changed, 0 insertions(+), 48 deletions(-)
diff --git
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-exec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 44d45fc..d974141 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -316,9 +316,9 @@ int cpu_exec(CPUState *env1)
#elif
On Fri, 15 Jan 2010 08:54:56 +0100
Gerd Hoffmann kra...@redhat.com wrote:
+static QString *get_sock_family(const struct sockaddr_storage *sa)
+{
+const char *name;
+
+switch (sa-ss_family)
+{
+case AF_INET:
+name = ipv4;
+break;
+
Since commit 747bbdf7 QEMU_WARN_UNUSED_RESULT is never defined as it is
conditional on a define from config-host.h which is included only later.
Include that file earlier to get the warnings back.
Reactivating it unfortunately leads to some warnings about unused qdev_init
results. These calls are
On Thu, 14 Jan 2010 15:20:10 -0600
Adam Litke a...@us.ibm.com wrote:
When using a control/QMP monitor in tandem with a regular monitor,
asynchronous
messages can get lost depending on the order of the QEMU program arguments.
QEMU events issued by monitor_protocol_event() always go to
On Fri, 2010-01-15 at 11:38 -0200, Luiz Capitulino wrote:
On Thu, 14 Jan 2010 15:20:10 -0600
Adam Litke a...@us.ibm.com wrote:
When using a control/QMP monitor in tandem with a regular monitor,
asynchronous
messages can get lost depending on the order of the QEMU program arguments.
When using a control/QMP monitor in tandem with a regular monitor, asynchronous
messages can get lost depending on the order of the QEMU program arguments.
QEMU events issued by monitor_protocol_event() always go to cur_mon. If the
user monitor was specified on the command line first (or it has
On Jan 15, 2010, at 8:56 AM, Paolo Bonzini wrote:
These are unused since edea5f0 (no need to define global registers in
cpu-exec.c, 2008-05-10).
Why not removing env_to_regs and regs_to_env ?
On Fri, 15 Jan 2010 08:34:02 -0600
Adam Litke a...@us.ibm.com wrote:
When using a control/QMP monitor in tandem with a regular monitor,
asynchronous
messages can get lost depending on the order of the QEMU program arguments.
QEMU events issued by monitor_protocol_event() always go to
On 01/15/2010 03:54 PM, Tristan Gingold wrote:
On Jan 15, 2010, at 8:56 AM, Paolo Bonzini wrote:
These are unused since edea5f0 (no need to define global registers in
cpu-exec.c, 2008-05-10).
Why not removing env_to_regs and regs_to_env ?
That's 2/3 indeed. :-)
Paolo
On Fri, 2010-01-15 at 13:00 -0200, Luiz Capitulino wrote:
The function will return on the first !QMP Monitor, the
right QLIST_FOREACH() body is:
if (monitor_ctrl_mode(mon)) {
monitor_json_emitter(mon, QOBJECT(qmp));
}
I'll ACK the respin.
Ah right, of course. Thanks and here it is.
On Fri, 15 Jan 2010 09:16:03 -0600
Adam Litke a...@us.ibm.com wrote:
On Fri, 2010-01-15 at 13:00 -0200, Luiz Capitulino wrote:
The function will return on the first !QMP Monitor, the
right QLIST_FOREACH() body is:
if (monitor_ctrl_mode(mon)) {
monitor_json_emitter(mon,
On 01/14/2010 04:38 PM, Richard Henderson wrote:
Previously, mmap_find_vma could return addresses not properly aligned
to the target page size. This of course led to all sorts of odd
problems down the road.
The trivial fix, to simply reject the unaligned address and continue
searching the
First patch is cleanup to get rid of an error that can't happen. Rest
are straightforward conversions.
Markus Armbruster (6):
monitor: Don't check for mon_get_cpu() failure
QError: New QERR_FOPEN_FAILED
monitor: convert do_memory_save() to QError
monitor: convert
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index 2da3800..6664a04 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1333,7 +1333,7 @@ static void do_physical_memory_save(Monitor *mon,
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index e7b8ca7..1c0b35e 100644
--- a/qerror.c
+++ b/qerror.c
@@ -81,6 +81,10 @@ static const QErrorStringTable
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c |4 ++--
qemu-monitor.hx |3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 6664a04..5f0a54c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -797,11 +797,11 @@ static void
mon_get_cpu() can't return null pointer, because it passes its return
value to cpu_synchronize_state() first, which crashes if its argument
is null.
Remove the (pretty cheesy) handling of this non-existing error.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c | 39
Signed-off-by: Markus Armbruster arm...@redhat.com
---
monitor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index 988de73..2da3800 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1306,7 +1306,7 @@ static void do_memory_save(Monitor *mon, const
Kevin Wolf kw...@redhat.com writes:
Since commit 747bbdf7 QEMU_WARN_UNUSED_RESULT is never defined as it is
conditional on a define from config-host.h which is included only later.
Include that file earlier to get the warnings back.
Reactivating it unfortunately leads to some warnings about
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 5f8fc5d..e7b8ca7 100644
--- a/qerror.c
+++ b/qerror.c
@@ -73,6 +73,10 @@ static const QErrorStringTable
Nathan Baum nat...@parenthephobia.org.uk writes:
This returns a QObject detailing the PCI-specific data about the device.
Signed-off-by: Nathan Baum nat...@parenthephobia.org.uk
---
hw/pci.c | 48
1 files changed, 48 insertions(+), 0
Nathan Baum nat...@parenthephobia.org.uk writes:
Returns a QObject with information about a USB device.
Signed-off-by: Nathan Baum nat...@parenthephobia.org.uk
---
hw/usb-bus.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/hw/usb-bus.c
Nathan Baum nat...@parenthephobia.org.uk writes:
Returns information about the system bus as a QObject.
Signed-off-by: Nathan Baum nat...@parenthephobia.org.uk
---
hw/sysbus.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/hw/sysbus.c
Nathan Baum nat...@parenthephobia.org.uk writes:
Places information about a bus and the devices on into a QObject.
Signed-off-by: Nathan Baum nat...@parenthephobia.org.uk
---
hw/qdev.c | 73
+
1 files changed, 73
Nathan Baum nat...@parenthephobia.org.uk writes:
Hullo.
This series of patches partially converts info qtree to QMP.
I've gone halfway: one can use query-qtree in QMP.
I haven't converted the old monitor function other than to rename it;
do_info_qtree_print just ignores the QObject it is
According to pages 9-31 - 9-34 of SuperSPARC MultiCache Controller
User's Manual:
1. A lower priority fault may not overwrite the
MFSR status of a higher priority fault.
2. The MFAR is overwritten according to the policy defined for the MFSR
3. The overwrite bit is asserted if the fault
On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
According to pages 9-31 - 9-34 of SuperSPARC MultiCache Controller
User's Manual:
1. A lower priority fault may not overwrite the
MFSR status of a higher priority fault.
2. The MFAR is overwritten according
This version improves support for multiple monitors and has been ported up to
HEAD as of 01/14.
Changes since V6:
- Integrated with virtio qdev feature bit changes
(specifically: Use VirtIODevice 'guest_features' to check if memory stats
is a negotiated feature)
- Track which monitor
The missing '@' broke 'udp::port@:port' parsing.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-char.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index b13f8d4..a8a92f5 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2314,7
On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/1/15 Blue Swirl blauwir...@gmail.com:
On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
According to pages 9-31 - 9-34 of SuperSPARC MultiCache Controller
User's Manual:
According to pages 9-31 - 9-34 of SuperSPARC MultiCache Controller
User's Manual:
1. A lower priority fault may not overwrite the
MFSR status of a higher priority fault.
2. The MFAR is overwritten according to the policy defined for the MFSR
3. The overwrite bit is asserted if the fault
Thanks, applied.
On Fri, Jan 15, 2010 at 9:28 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
According to pages 9-31 - 9-34 of SuperSPARC MultiCache Controller
User's Manual:
1. A lower priority fault may not overwrite the
MFSR status of a higher priority fault.
2. The MFAR is
2010/1/15 Blue Swirl blauwir...@gmail.com:
On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/1/15 Blue Swirl blauwir...@gmail.com:
On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
According to pages 9-31 - 9-34 of
2009/12/19 Blue Swirl blauwir...@gmail.com:
On Wed, Dec 16, 2009 at 2:10 PM, ange...@ntlworld.com wrote:
Hi,
Sorry if I can already find this answer somwhere on the Qemu site, but I
really would like to find out if QEMU support Solaris 2.6 as a Guest
operating system but can't find the
Don't clear interrupts on disabling, because
* Sun4M_SystemArchitecture_edited2.pdf doesn't describe
that masking or un-masking IRQ shall clear pending ones.
* Field tests also show that SPARCstation-20 doesn't
clear them.
* The patch makes Solaris 2.5.1/2.6 boot ~1500 times
faster (~20
after running some OBP/forth tests on a real SS-20 I must say that
most of our (especially my) speculations were wrong, as well as what
is written in
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR89C105.txt :
1. SS-20 may loose interrupts. At least if a timer interrupt was
46 matches
Mail list logo
