Aurelien Jarno 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 pressed (or
According to AMD document 21485D pp.141, APROMWE is bit 8 of BCR2.
Signed-off-by: Christopher Kilgour
---
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 *opaque, uint32_t
addr, uint3
On Tue, Feb 23, 2010 at 2: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
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 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 nic
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 interr
> 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 q
> 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. qemu_
> 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
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 corr
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
* Aurelien Jarno [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 determine
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 answe
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 t
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.
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
> ---
> I tagged this "FOR 0.12" because I think you might want to consider it
> for 0.12, not because I think it must go into
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
/usr/lib/gcc/arm-li
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 ad
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 app
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.
K
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)
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 t
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 mechanism
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 determi
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
---
target-ppc/translate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target
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.
On Sat, Feb 20, 2010 at 10:24:07AM -0800, Nathan Froyd wrote:
>
> Signed-off-by: Nathan Froyd
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
> index dfea6f6..de5
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
> ---
> target-mips/translate.c |2 +-
> 1 files changed
Stefan Weil schrieb:
> Stefan Weil schrieb:
>
>> 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
Kevin Wolf 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.
>
> Signed-
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:
Signed-off-by: Paolo Bonzini
---
cpu-exec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
ind
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 compile
> 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 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 ebp.
On 23 February 2010 17:03, Aurelien Jarno 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 problem seems
Thanks, applied.
On 2/23/10, Paolo Bonzini wrote:
> From: Avi Kivity
>
> Signed-off-by: Avi Kivity
> Signed-off-by: Paolo Bonzini
> ---
> osdep.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/osdep.c b/osdep.c
> index 3bab79a..4d39f2c 100644
> --- a/os
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 aff
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 memory.
Kevin Wolf 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 to completel
Kevin Wolf wrote:
> Implement some more refcount block related checks
>
> Signed-off-by: Kevin Wolf
> ---
> block/qcow2-refcount.c | 12
> 1 files changed, 12 insertions(+), 0 deletions(-)
Acked-by: Juan Quintela
Kevin Wolf 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 suggested take t
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
>>
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
Implement some more refcount block related checks
Signed-off-by: Kevin Wolf
---
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
--- a/block/qcow2-refcount.c
+
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 de
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 co
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:
A
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;
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
---
block/
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(-)
From: Jan Kiszka
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 into the kernel.
Signed-
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 = (host_r
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 po
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'
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 torwa
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 r
From: Avi Kivity
Signed-off-by: Avi Kivity
Signed-off-by: Paolo Bonzini
---
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 +293,9 @@ ssize_t qemu_write_full(int fd, const vo
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 torwards what coreboot does, or
> > > did you have a differe
58 matches
Mail list logo
