28.07.2017 14:53, Eduardo Otubo wrote:
> Starting qemu-system-unicore32 without the -kernel parameter results in
> an assert() returns false and aborts qemu. This patch replaces it with a
> proper error message followed by exit(1).
Applied to -trivial, thanks!
/mjt
Starting qemu-system-unicore32 without the -kernel parameter results in
an assert() returns false and aborts qemu. This patch replaces it with a
proper error message followed by exit(1).
Signed-off-by: Eduardo Otubo
---
hw/unicore32/puv3.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-
On 07/26/2017 01:05 PM, Thomas Huth wrote:
On 26.07.2017 18:00, Philippe Mathieu-Daudé wrote:
On 07/26/2017 12:04 PM, Eduardo Otubo wrote:
Starting qemu-system-unicore32 without the -kernel parameter results in
an assert() returns false and aborts qemu. This patch replaces it with a
proper erro
On 26.07.2017 18:00, Philippe Mathieu-Daudé wrote:
> On 07/26/2017 12:04 PM, Eduardo Otubo wrote:
>> Starting qemu-system-unicore32 without the -kernel parameter results in
>> an assert() returns false and aborts qemu. This patch replaces it with a
>> proper error message followed by exit(1).
>>
>>
On 07/26/2017 12:04 PM, Eduardo Otubo wrote:
Starting qemu-system-unicore32 without the -kernel parameter results in
an assert() returns false and aborts qemu. This patch replaces it with a
proper error message followed by exit(1).
Signed-off-by: Eduardo Otubo
---
hw/unicore32/puv3.c | 5
On 26.07.2017 17:04, Eduardo Otubo wrote:
> Starting qemu-system-unicore32 without the -kernel parameter results in
> an assert() returns false and aborts qemu. This patch replaces it with a
> proper error message followed by exit(1).
>
> Signed-off-by: Eduardo Otubo
> ---
> hw/unicore32/puv3.c
On 07/26/2017 11:28 AM, Cleber Rosa wrote:
>
>
> On 07/26/2017 11:04 AM, Eduardo Otubo wrote:
>> Starting qemu-system-unicore32 without the -kernel parameter results in
>> an assert() returns false and aborts qemu. This patch replaces it with a
>> proper error message followed by exit(1).
>>
>>
On 07/26/2017 11:04 AM, Eduardo Otubo wrote:
> Starting qemu-system-unicore32 without the -kernel parameter results in
> an assert() returns false and aborts qemu. This patch replaces it with a
> proper error message followed by exit(1).
>
> Signed-off-by: Eduardo Otubo
> ---
> hw/unicore32/pu
On 26/07/2017 17:04, Eduardo Otubo wrote:
> Starting qemu-system-unicore32 without the -kernel parameter results in
> an assert() returns false and aborts qemu. This patch replaces it with a
> proper error message followed by exit(1).
>
> Signed-off-by: Eduardo Otubo
> ---
> hw/unicore32/puv3.c
Starting qemu-system-unicore32 without the -kernel parameter results in
an assert() returns false and aborts qemu. This patch replaces it with a
proper error message followed by exit(1).
Signed-off-by: Eduardo Otubo
---
hw/unicore32/puv3.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-
With more information at hand with the reference manual from Freescale
http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf , I was able to
revisit my patch and figure out what is actually going on.
Before applying any patch, efscmp* instructions in QEMU set crD values as
(0b0100 << 2) = 0b1
Adding some more basis to the patch:
I received some documentation from Freescale support relating to this:
Signal Processing Engine (SPE) Programming Environments Manual:
http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf.
Relevant info is on page #113.
According to the documentation, t
Hi Everyone,
Please find attached a patch which fixes handling in QEMU PPC e500v1 for efscmp*
instructions. This was the cause of over 400 FAILs for this CPU while running
GCC testsuite, which have been fixed.
Value for Condition Registers (CR) being set in QEMU was different from
the value obser
On Thu, 22 Jan 2015, Don Slutz wrote:
> On 01/22/15 13:46, Stefano Stabellini wrote:
> > xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an
> > unsigned long argument (in fact xen_pfn_t is defined as uint64_t on
> > ARM).
> >
> > Also use xc_hvm_param_get instead of the deprecated xc
On 01/22/15 13:46, Stefano Stabellini wrote:
> xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an
> unsigned long argument (in fact xen_pfn_t is defined as uint64_t on
> ARM).
>
> Also use xc_hvm_param_get instead of the deprecated xc_get_hvm_param.
>
> Signed-off-by: Stefano Stabel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/22/15 13:46, Stefano Stabellini wrote:
> xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an
> unsigned long argument (in fact xen_pfn_t is defined as uint64_t
> on ARM).
>
> Also use xc_hvm_param_get instead of the deprecated
> xc
xen_get_vmport_regs_pfn should take a xen_pfn_t argument, not an
unsigned long argument (in fact xen_pfn_t is defined as uint64_t on
ARM).
Also use xc_hvm_param_get instead of the deprecated xc_get_hvm_param.
Signed-off-by: Stefano Stabellini
diff --git a/include/hw/xen/xen_common.h b/include/h
Please repost a proper v2.
Regards,
Anthony Liguori
On Sun, Dec 8, 2013 at 7:28 PM, Brad Smith wrote:
> On 27/11/13 6:15 PM, Brad Smith wrote:
>>
>> This resolves the build issue with building the ROMs on OpenBSD on x86
>> archs.
>> As of OpenBSD 5.3 the compiler builds PIE binaries by default
On 27/11/13 6:15 PM, Brad Smith wrote:
This resolves the build issue with building the ROMs on OpenBSD on x86 archs.
As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus the
whole OS/packages and so forth. The ROMs need to have PIE disabled. This
is my initial attempt at trying
This resolves the build issue with building the ROMs on OpenBSD on x86 archs.
As of OpenBSD 5.3 the compiler builds PIE binaries by default and thus the
whole OS/packages and so forth. The ROMs need to have PIE disabled. This
is my initial attempt at trying to get somehting upstream so that QEMU
bo
On 10 August 2012 20:48, Stefan Weil wrote:
> One more...
No problem with the patch but your commit message summary
implies a rather wider effect than the patch actually has :-)
-- PMM
One more...
Signed-off-by: Stefan Weil
---
scripts/simpletrace.py |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/simpletrace.py b/scripts/simpletrace.py
index 1e74e75..9fce4bb 100755
--- a/scripts/simpletrace.py
+++ b/scripts/simpletrace.py
@@ -71,7 +71,7 @@ def r
On Wed, Jul 04, 2012 at 10:51:25AM +0800, Dunrong Huang wrote:
>There have been two discussions about this error:
>http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04858.html
>and
>http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04728.html
>
Oh, thank you!
>
>2012/7/4 Wanpeng
There have been two discussions about this error:
http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04858.html
and
http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04728.html
2012/7/4 Wanpeng Li :
> From: Wanpeng Li
>
> CC i386-softmmu/target-i386/translate.o
> /home/kerne
From: Wanpeng Li
CC i386-softmmu/target-i386/translate.o
/home/kernel/qemu/target-i386/translate.c: In function ‘gen_sse’:
/home/kernel/qemu/target-i386/translate.c:3571:27: error: assignment from
incompatible pointer type [-Werror]
/home/kernel/qemu/target-i386/translate.c:3573:17: error:
On 09/21/11 12:16, Stefan Hajnoczi wrote:
On Wed, Sep 21, 2011 at 10:34 AM, Christoph Egger
wrote:
When NAS (http://nas.sf.net) is installed then there
is an existing audio/audio.h. Then when compiling
qemu, #include "audio/audio.h" takes the one from NAS
and causes the build to fail.
So ren
On Wed, Sep 21, 2011 at 10:34 AM, Christoph Egger
wrote:
>
> When NAS (http://nas.sf.net) is installed then there
> is an existing audio/audio.h. Then when compiling
> qemu, #include "audio/audio.h" takes the one from NAS
> and causes the build to fail.
>
> So rename audio/audio.h to audio/qaudio.
When NAS (http://nas.sf.net) is installed then there
is an existing audio/audio.h. Then when compiling
qemu, #include "audio/audio.h" takes the one from NAS
and causes the build to fail.
So rename audio/audio.h to audio/qaudio.h and adjust
all users.
Signed-off-by: Christoph Egger
diff --git
On Mar 05 Jul 2011 07:08:23 Wesley W. Terpstra escribió:
> I also recently tried to get a mipsel debian/sid chroot running under my
> amd64/squeeze system. As posted by Lisandro earlier this month, it didn't
> work. ;-) There are several problems, the most glaring of which the
> attached patch fixe
On 5 July 2011 11:08, Wesley W. Terpstra wrote:
> I also recently tried to get a mipsel debian/sid chroot running under my
> amd64/squeeze system. As posted by Lisandro earlier this month, it didn't
> work. ;-) There are several problems, the most glaring of which the attached
> patch fixes.
Than
I also recently tried to get a mipsel debian/sid chroot running under my
amd64/squeeze system. As posted by Lisandro earlier this month, it didn't
work. ;-) There are several problems, the most glaring of which the attached
patch fixes. I'll break down the changes:
1. Return -TARGET_ENOSYS instead
On 05/01/2010 09:38 PM, Kevin O'Connor wrote:
The QEMU USB mouse claims to support the "boot" protocol
(bInterfaceSubClass is 1). However, the mouse rejects the
Set_Protocol command.
The qemu mouse does support the "boot" protocol specification, so a
simple fix is to just enable the Set_Portoco
On Sun, May 02, 2010 at 02:04:44PM +0300, Shahar Havivi wrote:
> On Sat, May 01, 2010 at 10:38:51PM -0400, Kevin O'Connor wrote:
> > The QEMU USB mouse claims to support the "boot" protocol
> > (bInterfaceSubClass is 1). However, the mouse rejects the
> > Set_Protocol command.
> >
> > The qemu mo
On Sat, May 01, 2010 at 10:38:51PM -0400, Kevin O'Connor wrote:
> Date: Sat, 1 May 2010 22:38:51 -0400
> From: Kevin O'Connor
> To: qemu-devel@nongnu.org, seab...@seabios.org
> Cc:
> Subject: [Qemu-devel] [PATCH] Fix qemu mouse Set_Protocol behavior
>
> The QEMU
The QEMU USB mouse claims to support the "boot" protocol
(bInterfaceSubClass is 1). However, the mouse rejects the
Set_Protocol command.
The qemu mouse does support the "boot" protocol specification, so a
simple fix is to just enable the Set_Portocol request.
-Kevin
--- a/hw/usb-hid.c
+++ b/hw
Signed-off-by: Aurelien Jarno
---
qemu-options.hx |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index f53922f..7daa246 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1029,7 +1029,7 @@ the guest, use the following:
@example
On Thursday 28 January 2010 17:17:22 Kevin Wolf wrote:
> Am 28.01.2010 06:22, schrieb Sheng Yang:
> > Commit 03cbdac7 "Disable fall-back to read-only when cannot open drive's
> > file for read-write" result in read-only image can't be used as backed
> > image in qemu-img.
> >
> > CC: Naphtali Sprei
Am 28.01.2010 06:22, schrieb Sheng Yang:
> Commit 03cbdac7 "Disable fall-back to read-only when cannot open drive's
> file for read-write" result in read-only image can't be used as backed
> image in qemu-img.
>
> CC: Naphtali Sprei
> Signed-off-by: Sheng Yang
> ---
>
> This issue blocked our Q
Commit 03cbdac7 "Disable fall-back to read-only when cannot open drive's
file for read-write" result in read-only image can't be used as backed
image in qemu-img.
CC: Naphtali Sprei
Signed-off-by: Sheng Yang
---
This issue blocked our QA's KVM nightly test. But in fact, I don't like this
patch,
The CPU hotplug patches have not been applied to QEMU yet.
Regards,,
Anthony Liguori
Jerone Young wrote:
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1204150440 21600
# Branch merge
# Node ID f255b23b6ef9461be4ee18fa0745f30c4fb66e6a
# Parent 64a281615f436e65ca7fb2f3c272
For go this patch. It was not in upstream qemu.
On Wed, 2008-02-27 at 16:35 -0600, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <[EMAIL PROTECTED]>
> # Date 1204150440 21600
> # Branch merge
> # Node ID f255b23b6ef9461be4ee18fa0745f30c4fb66e6a
> # Parent 64a281615f436e65ca7fb2
# HG changeset patch
# User Jerone Young <[EMAIL PROTECTED]>
# Date 1204150440 21600
# Branch merge
# Node ID f255b23b6ef9461be4ee18fa0745f30c4fb66e6a
# Parent 64a281615f436e65ca7fb2f3c2721c374fbfc8be
Fix qemu PPC breakage in monitor.c
Recent pull of qemu_cvs has added function "qemu_system_cpu_h
> Are you sure it is needed ? I made a different fix a few days ago.
>
> Regards,
>
> Fabrice.
>
>
I wrote my fix before your fix was available.
At least for raw disk images, your fix also works,
so at the moment, there is no need for my patch
(this should be checked with other kinds of disk
imag
Stefan Weil wrote:
Hello,
qemu fails when the disk image file is writable but on
a readonly filesystem (so it is not really writable).
The patch below fixes this. It also declares a local
function "static" (maybe this part of the patch is a
matter of taste).
Are you sure it is needed ? I made
Hello,
qemu fails when the disk image file is writable but on
a readonly filesystem (so it is not really writable).
The patch below fixes this. It also declares a local
function "static" (maybe this part of the patch is a
matter of taste).
Regards,
Stefan
--- block.c 19 Aug 2006 11:45:59 -
qemu hangs when an i386 Linux host resumes from suspend (swsusp2),
because the host's TSC is reset to a value lower than it was before
the suspend.
Although this is a bug in the host OS, the attached patch (originally
from John Coiner) is simple and makes qemu more resilient to weird
host tick co
I can confirm this patch applied alone to 0.7.2 did something for me. I
suspended the PC for 1 minute (just to reboot the machine) and after
resume, my quest win95 was still working. I will of course try longer
periods later.
Peter
John Coiner wrote:
>
> After I hibernate my x86 linux host mach
After I hibernate my x86 linux host machine (using the "swsusp2"
package) and resume, QEMU and guest hang. That is odd, because
hibernation is transparent to all other user programs.
Has anyone else noticed this? If so please try the patch.
You know QEMU is doing something weird, for it to b
48 matches
Mail list logo
