From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
osdep.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/osdep.c b/osdep.c
index 3bab79a..4d39f2c 100644
--- a/osdep.c
+++ b/osdep.c
@@ -293,9
Am 22.02.2010 22:22, schrieb Daniel Gutson:
[Re-done with git.]
With this patch, 'gdb detach' correctly resumes the inferior execution
after detaching the debugger.
The bug was caused by qemu asking gdb to execute a syscall (isatty)
after the detach, and then waiting (forever) for the
On 02/23/2010 02:22 AM, Gleb Natapov wrote:
On Mon, Feb 22, 2010 at 08:31:00PM -0500, Kevin O'Connor wrote:
On Mon, Feb 22, 2010 at 10:33:12AM +0200, Gleb Natapov wrote:
On Sun, Feb 21, 2010 at 02:13:51PM -0500, Kevin O'Connor wrote:
Are you thinking of moving qemu more
On Tue, Feb 23, 2010 at 07:50:16AM -0600, Anthony Liguori wrote:
On 02/23/2010 02:22 AM, Gleb Natapov wrote:
On Mon, Feb 22, 2010 at 08:31:00PM -0500, Kevin O'Connor wrote:
On Mon, Feb 22, 2010 at 10:33:12AM +0200, Gleb Natapov wrote:
On Sun, Feb 21, 2010 at 02:13:51PM -0500, Kevin O'Connor
So far we synchronized any dirty VCPU state back into the kernel before
updating the guest debug state. This was a tribute to a deficit in x86
kernels before KVM_CAP_X86_ROBUST_SINGLESTEP. But as this is an
arch-dependent issue, it is better handle in the x86 part of KVM and
remove the writeback
I'm building QEMU mipsel-linux-user with Ubuntu's GCC 4.4 on an x86
host. Whenever I try to run a trivial MIPS executable, QEMU segfaults
in cpu_loop() shortly after the call to cpu_mips_exec().
The problem seems to be that cpu_exec() doesn't preserve ebp. It tries to:
saved_env_reg =
From: Jan Kiszka jan.kis...@siemens.com
This should explain a lot of the weird breakages of upstream KVM we've
seen recently (actually we should have seen it much earlier):
Stop translating eflags into TCG format when in kvm mode as we never
translate it back and rather sync this broken state
Just one patch, fixing eflags corruption. Also available from git:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/stable-0.12
Please pull.
Jan Kiszka (1):
kvm: Fix eflags corruption in kvm mode
cpu-exec.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
When checking for errors, commit db89119d compares with the wrong values,
failing image creation even when there was no error. Additionally, if an
error has occured, we can't preallocate the image (it's likely broken).
This unbreaks test 023 of qemu-iotests.
Signed-off-by: Kevin Wolf
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M memsize.
This patch adds a simple check and error message (much like the 2047 limit on
32-bit hosts) on ram_size in the control path after we determine we're
not using kvm
Upstream qemu-kvm is affected if using the -no-kvm option;
The current implementation of alloc_refcount_block and grow_refcount_table has
fundamental problems regarding error handling. There are some places where an
I/O error means that the image is going to be corrupted. I have found that the
only way to fix this is to completely rewrite the thing.
v2:
When the refcount table grows, it doesn't only grow by one entry but reserves
some space for future refcount blocks. The algorithm to calculate the number of
entries stays the same with the fixes, so factor it out before replacing the
rest.
As Juan suggested take the opportunity to simplify the
The current implementation of alloc_refcount_block and grow_refcount_table has
fundamental problems regarding error handling. There are some places where an
I/O error means that the image is going to be corrupted. I have found that the
only way to fix this is to completely rewrite the thing.
In
Implement some more refcount block related checks
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/qcow2-refcount.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index f714ca2..917fc88 100644
---
Alexander Graf wrote:
I guess what you really want is some shm region between host and guess
that you can use as ring buffer. Then you could run a timer on the host
side to flush it or have some sort of callback when you urgently need to
flush it manually.
The benefit here is that you can
On 23.02.2010, at 16:46, Ian Molton wrote:
Alexander Graf wrote:
I guess what you really want is some shm region between host and guess
that you can use as ring buffer. Then you could run a timer on the host
side to flush it or have some sort of callback when you urgently need to
flush it
Kevin Wolf kw...@redhat.com wrote:
When the refcount table grows, it doesn't only grow by one entry but reserves
some space for future refcount blocks. The algorithm to calculate the number
of
entries stays the same with the fixes, so factor it out before replacing the
rest.
As Juan
Kevin Wolf kw...@redhat.com wrote:
Implement some more refcount block related checks
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/qcow2-refcount.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
Acked-by: Juan Quintela quint...@redhat.com
Kevin Wolf kw...@redhat.com wrote:
The current implementation of alloc_refcount_block and grow_refcount_table has
fundamental problems regarding error handling. There are some places where an
I/O error means that the image is going to be corrupted. I have found that the
only way to fix this is
On 02/22/2010 11:47 AM, Ian Molton wrote:
Anthony Liguori wrote:
On 02/22/2010 10:46 AM, Ian Molton wrote:
Anthony Liguori wrote:
cpu_physical_memory_map().
But this function has some subtle characteristics. It may return a
bounce buffer if you attempt to map MMIO
Ryan Harper a écrit :
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M memsize.
This patch adds a simple check and error message (much like the 2047 limit on
32-bit hosts) on ram_size in the control path after we determine we're
not using kvm
Upstream qemu-kvm is affected
Thanks, applied.
On 2/23/10, Paolo Bonzini pbonz...@redhat.com wrote:
From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
osdep.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On 23 February 2010 17:03, Aurelien Jarno aurel...@aurel32.net wrote:
Jay Foad a écrit :
I'm building QEMU mipsel-linux-user with Ubuntu's GCC 4.4 on an x86
host. Whenever I try to run a trivial MIPS executable, QEMU segfaults
in cpu_loop() shortly after the call to cpu_mips_exec().
The
On 02/23/2010 03:50 PM, Jay Foad wrote:
I'm building QEMU mipsel-linux-user with Ubuntu's GCC 4.4 on an x86
host. Whenever I try to run a trivial MIPS executable, QEMU segfaults
in cpu_loop() shortly after the call to cpu_mips_exec().
The problem seems to be that cpu_exec() doesn't preserve
Can you try this patch:
It works! Thanks.
and if it works, possibly only each hunk of it?
Just the first hunk: works!
Just the second hunk: doesn't work
Can you explain why the volatile is necessary? Or is it working around
a problem with the compiler?
Thanks,
Jay.
On 02/23/2010 07:17 PM, Jay Foad wrote:
Can you try this patch:
It works! Thanks.
and if it works, possibly only each hunk of it?
Just the first hunk: works!
Just the second hunk: doesn't work
Can you explain why the volatile is necessary? Or is it working around
a problem with the
This ensures that the compiler does not move it away from
the env = env1; assignment. Fixes a miscompilation
on gcc 4.4, reported by Jay Foad.
Cc: jay.f...@gmail.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
cpu-exec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
Kevin Wolf kw...@redhat.com wrote:
When checking for errors, commit db89119d compares with the wrong values,
failing image creation even when there was no error. Additionally, if an
error has occured, we can't preallocate the image (it's likely broken).
This unbreaks test 023 of qemu-iotests.
On Sat, Feb 20, 2010 at 10:19:09AM -0800, Nathan Froyd wrote:
When we signal a CpU exception for coprocessor 0, we should indicate
that it's for coprocessor 0 instead of coprocessor 1.
Thanks applied.
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/translate.c |2
On Sat, Feb 20, 2010 at 10:24:07AM -0800, Nathan Froyd wrote:
Signed-off-by: Nathan Froyd froy...@codesourcery.com
Thanks applied.
---
target-mips/translate.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
The CRF_{CH,CL,CH_OR_CL,CH_AND_CL} constants were all off by one bit
position. Because of this, the SPE evcmp* family of instructions would
store values in the result condition register that were also off by one
bit position.
Fixed by using the CRF_{LT,GT,EQ,SO} constants for the shift amounts.
The shifts in the gen_evsplat* functions were expecting rA to be masked,
not extracted, and so used the wrong shift amounts to sign-extend or pad
with zeroes.
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-ppc/translate.c |4 ++--
1 files changed, 2 insertions(+), 2
On 23.02.2010, at 18:02, Aurelien Jarno wrote:
Ryan Harper a écrit :
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M memsize.
This patch adds a simple check and error message (much like the 2047 limit on
32-bit hosts) on ram_size in the control path after we determine
Support for passing memory regions via VirtIO to remove need for PCI
support in the guest.
Adds new vectors to VirtIO config space to pass memory regions similar
to how virtqueues are passed.
Kernel patch is forthcoming that add device_ops to access the memory regions.
I have used this
Hi Cam,
On 02/23/2010 02:52 PM, Cam Macdonell wrote:
Support for passing memory regions via VirtIO to remove need for PCI
support in the guest.
Adds new vectors to VirtIO config space to pass memory regions similar
to how virtqueues are passed.
Kernel patch is forthcoming that add device_ops
On 02/23/2010 02:30 PM, Alexander Graf wrote:
On 23.02.2010, at 18:02, Aurelien Jarno wrote:
Ryan Harper a écrit :
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M memsize.
This patch adds a simple check and error message (much like the 2047 limit on
32-bit hosts)
On 02/23/2010 03:05 PM, Anthony Liguori wrote:
Hi Cam,
On 02/23/2010 02:52 PM, Cam Macdonell wrote:
Support for passing memory regions via VirtIO to remove need for PCI
support in the guest.
Adds new vectors to VirtIO config space to pass memory regions similar
to how virtqueues are passed.
On 02/23/2010 12:42 PM, Stefan Weil wrote:
I'd commit it myself if I had the rights, but I haven't.
So the only think I can do is remind those who have...
Please resubmit. I would expect an ARM host patch to be applied by Paul
but if he's not available to, I'll keep it my queue to be
On Tue, Feb 23, 2010 at 03:07:20PM -0600, Anthony Liguori wrote:
On 02/23/2010 02:30 PM, Alexander Graf wrote:
On 23.02.2010, at 18:02, Aurelien Jarno wrote:
Ryan Harper a écrit :
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M
memsize.
This patch adds a simple check
Compilation of m68k-softmmu or m68k-linux-user on arm host
(or cross compilation for arm) results in a linker warning:
LINK m68k-softmmu/qemu-system-m68k
m68k-dis.o: warning: definition of `floatformat_ieee_single_little' overriding
common
arm-dis.o: warning: common is here
On Mon, Dec 14, 2009 at 10:48:05AM +0100, Markus Armbruster wrote:
No functional change. Bonus: looks just like qemu_malloc() now.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
I tagged this FOR 0.12 because I think you might want to consider it
for 0.12, not because I think it
On Wed, Dec 09, 2009 at 12:07:50PM +0100, Soren Hansen wrote:
The mouse_button monitor command currently results in a call like this:
kbd_mouse_event(0, 0, 0, mouse_button_status);
For a pointer in relative mode, this means a button gets pressed (or
or released) and nothing else.
The qemu-system-ppcemb binary has the same -M and -cpu options as qemu-system-
ppc. The default-configs/*.mak files are identical for ppc-softmmu.mak and
ppcemb-softmmu.mak. The ppc-softmmu/config-target.mak matches the one in
ppcemb-softmmu. The config-target.mak files differ, but just in
On Tue, Feb 23, 2010 at 03:37:16PM -0600, Rob Landley wrote:
I've been building a powerpc4xx system image, but booting it under g3beige
because last I checked qemu doesn't emulate a 4xx processor? (It has a
bamboo
board, but only lets you use it under kvm...)
This part is easy to answer:
* Aurelien Jarno aurel...@aurel32.net [2010-02-23 11:37]:
Ryan Harper a écrit :
Currently, x86_64-softmmu qemu segfaults when trying to use 4095M memsize.
This patch adds a simple check and error message (much like the 2047 limit
on
32-bit hosts) on ram_size in the control path after we
On Mon, Jan 04, 2010 at 02:46:05PM -0800, Richard Henderson wrote:
I've split up the FPCR as requested by Aurelien. We no longer
set anything in FP_STATUS after the execution of the operation,
only copy data from FP_STATUS to some env-fpcr field.
I have totally rewritten the patch to be
10% of saved PPMs are corrupted or empty, hard disk images are
randomly corrupted.
Tested under Mac OS X 10.6.1 (x86-64) and under Linux 2.6.31-gentoo-r1
(x86-64) using QEMU 0.12.2 (manually compiled both)
No other program corrupts files (cp, Finder, Mail, TextEdit), neither
they are
I suggest these steps:
1. Debug output to stdout is no longer accepted for new / modified code.
2. New or modified debug messages should go to stderr.
I don't see this as a real improvement. Arguably these aren't errors, so
stdout is where they should be going.
If we're going to do
Bottom halves are run at the very end of the event loop which means that
they're guaranteed to be the last thing run. idle bottom halves can be
rescheduled without causing an infinite loop and do not affect the
select timeout (which normal bottom halves do).
Idle bottom halves (i.e.
vnet_hdr is IMHO a really bad example to copy from.
vnet_hdr leaks into the migration state via n-has_vnet_hdr. What this
means is that if you want to migrate from -net tap -net nic,model=virtio
to -net user -net nic,model=virtio, it will fail.
This is a hard problem to solve in qemu
Could one of the developers give a brief status of the current state of support
for PCIe and MSI-X interrupts in Qemu.
I'm trying to build a System-C device that I'd like to co-simulate with Qemu
and have the ability to use the same software stack as well. The kernel modules
rely on MSI-X
On Wed, Feb 24, 2010 at 03:14:25AM +, Paul Brook wrote:
vnet_hdr is IMHO a really bad example to copy from.
vnet_hdr leaks into the migration state via n-has_vnet_hdr. What this
means is that if you want to migrate from -net tap -net nic,model=virtio
to -net user -net
These are the kernel changes to support passing memory regions via VirtIO that
was emailed earlier. This patch adds new device_ops to the VirtIO device
which are map and unmap. These operations are based on suggestions from
Christian Borntraeger (but don't blame him for this patch) from the
On Tue, Feb 23, 2010 at 2:05 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Hi Cam,
On 02/23/2010 02:52 PM, Cam Macdonell wrote:
Support for passing memory regions via VirtIO to remove need for PCI
support in the guest.
Adds new vectors to VirtIO config space to pass memory regions
According to AMD document 21485D pp.141, APROMWE is bit 8 of BCR2.
Signed-off-by: Christopher Kilgour tec...@whiterocker.com
---
diff --git a/hw/pcnet.c b/hw/pcnet.c
index 44b5b31..f889898 100644
--- a/hw/pcnet.c
+++ b/hw/pcnet.c
@@ -1601,7 +1601,7 @@ static void pcnet_aprom_writeb(void
Aurelien Jarno aurel...@aurel32.net writes:
On Wed, Dec 09, 2009 at 12:07:50PM +0100, Soren Hansen wrote:
The mouse_button monitor command currently results in a call like this:
kbd_mouse_event(0, 0, 0, mouse_button_status);
For a pointer in relative mode, this means a button gets
56 matches
Mail list logo
