This patch complements Partial IDE DVD emulation and the previous patch to
reflect that the device is now able to support DVDs by changing the reported
model to be DVD-ROM instead of CD-ROM.
Carlo
---
Index: hw/ide.c
===
RCS file:
On 11/30/07, Paul Brook [EMAIL PROTECTED] wrote:
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
The following patch enforces that the sh4 target is 32
On Fri, Nov 30, 2007 at 05:15:21PM +, Paul Brook wrote:
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
in the sh4 specific case, it doesn't make sense for sh4 to print an access
error to a physical address that
Hi,
What is current situation with Host ARM and guest X86?
We are planning to use such combination on PXA320 based system
(forced to use Wine). What do you think guys, is it wise, to spend time
and money trying to do it?
Best Wishes,
Val.
Blue Swirl-2 wrote:
On 11/28/07, TeLeMan [EMAIL PROTECTED] wrote:
dyngen_code() can generate more than CODE_GEN_MAX_SIZE bytes,
code_gen_buffer
can be overflowed. I hope this security bug will be fixed soon.
Thank you for the analysis. It's true that cpu_gen_code does not pass
On Fri, 30 Nov 2007, Jeremy C. Reed wrote:
The pkgsrc build system has several patches against qemu 0.9.0.
They are at:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/emulators/qemu/patches/
Do you want them submitted in a certain way?
I forgot to mention that patch-ag above is wrong as it
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
The following patch enforces that the sh4 target is 32 bit to prevent
qemu to expand incorrectly to a 64
The following patch series complements Partial IDE DVD emulation which was
added in revision 1.66 of ide.c and that was generating the following timeouts
for OpenSolaris guests when trying to access the ATAPI CD-ROM (during
installation for example):
WARNING: /[EMAIL PROTECTED],0/[EMAIL
target_phys_addr_t = physical address of the host
ram_addr_t = physical address of the guest
No, target_phys_addr_t is the physical address of the emulated target
system. For host addresses ram_addr_t, unsigned long or even int is
used. Host addresses are of course virtual, Qemu is a
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1 07/11/30 16:45:21
Modified files:
. : monitor.c
Log message:
Fix a crash with monitor input arriving before readline_start has been
called
CVSWeb URLs:
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
The following patch enforces that the sh4 target is 32 bit to prevent qemu
to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.
This is wrong. As the comment in cpu-defs.h says, target_phys_addr_t may need
to be
What about my bug report? Up to now I got no replies.
Please include the patch in CVS HEAD - or tell me why you won't do so.
Kind regards
Stefan
Stefan Weil schrieb:
Are there no comments?
What is needed to get this fixed in QEMU CVS?
Do you need additional information?
Stefan
Here is a
The following patch enforces that the sh4 target is 32 bit to prevent qemu to
expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.
Carlo
---
Index: target-sh4/cpu.h
===
RCS file:
On Fri, Nov 30, 2007 at 05:37:35PM +0200, Blue Swirl wrote:
On 11/30/07, Carlo Marcelo Arenas Belon [EMAIL PROTECTED] wrote:
which might not be what was intended originally and might be uncovering a
bug somewhere else and based on the fact that apparently (and this gets
confusing as it
On 11/30/07, Paul Brook [EMAIL PROTECTED] wrote:
I think T2 may need to store host addresses as well. To be frank, I
don't understand that part but there is a compiler warning on a 64
bit host.
If you're thinking of the warnings in op_goto_tb0, these are actually due to
tb-tb_next having
I think T2 may need to store host addresses as well. To be frank, I
don't understand that part but there is a compiler warning on a 64
bit host.
If you're thinking of the warnings in op_goto_tb0, these are actually due to
tb-tb_next having the wrong type.
In general all access to target
andrzej zaborowski wrote:
On 30/11/2007, Andre Przywara [EMAIL PROTECTED] wrote:
These casts are not the right way to get rid of the warnings, as are
some of the casts in other files in qemu_put_* and qemu_get_*
arguments. In this case the warnings are true positives and the bugs
The following patch implements the following changes to the implementation of
GET CONFIGURATION as part of the initial MMC-6 support added to ide.c so it
would emulate a multi profile device with DVD-ROM capabilities :
* recognize and honor Allocation Length command parameter
* corrected flags
On 11/30/07, Paul Brook [EMAIL PROTECTED] wrote:
target_phys_addr_t = physical address of the host
ram_addr_t = physical address of the guest
No, target_phys_addr_t is the physical address of the emulated target
system. For host addresses ram_addr_t, unsigned long or even int is
On 30/11/2007, Andre Przywara [EMAIL PROTECTED] wrote:
These casts are not the right way to get rid of the warnings, as are
some of the casts in other files in qemu_put_* and qemu_get_*
arguments. In this case the warnings are true positives and the bugs
causing the warnings have to be
Also, if you disable profiling, the monitor.c file doesnt compile.
And due to request, the unified diff is on this message (as an attachment)
- Original Message -
From: Sylvain Petreolle [EMAIL PROTECTED]
To: qemu-devel@nongnu.org
Sent: Wednesday, November 28, 2007 10:28 AM
Subject: Re :
Andrzej,
These casts are not the right way to get rid of the warnings, as are
some of the casts in other files in qemu_put_* and qemu_get_*
arguments. In this case the warnings are true positives and the bugs
causing the warnings have to be addressed instead of just the
warnings.
Are you
On Thu, Nov 29, 2007 at 05:46:08PM +0100, Tristan Gingold wrote:
On Nov 29, 2007, at 4:07 PM, Carlo Marcelo Arenas Belon wrote:
On Thu, Nov 29, 2007 at 02:05:36PM +0100, Tristan Gingold wrote:
The pending interrupt condition shall be set by:
??? the completion of a command; or
This
On Fri, Nov 30, 2007 at 02:36:32PM +0900, Magnus Damm wrote:
On Nov 19, 2007 6:18 AM, Carlo Marcelo Arenas Belon
[EMAIL PROTECTED] wrote:
The following patch changes the formatting string from %08x to
TARGET_FMT_plx
to accommodate for compilation in 64bit hosts and that manifests with the
What solution do you prefer for the opaque types? I have used the simple:
-void *args[MAX_ARGS];
+intptr_t args[MAX_ARGS];
A more portable and clean solution would be this:
-void *args[MAX_ARGS];
+union
+{
+void* ptr;
+int i;
+}
On 11/30/07, Jeremy C. Reed [EMAIL PROTECTED] wrote:
On Fri, 30 Nov 2007, Jeremy C. Reed wrote:
The pkgsrc build system has several patches against qemu 0.9.0.
They are at:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/emulators/qemu/patches/
Do you want them submitted in a certain
Andre Przywara, le Fri 30 Nov 2007 15:10:07 +0100, a écrit :
A more portable and clean solution would be this:
-void *args[MAX_ARGS];
+union
+{
+void* ptr;
+int i;
+} args[MAX_ARGS];
It's not more portable: C99 doesn't asserts that if you write ptr and
read
On Thursday 29 November 2007, André Przywara wrote:
-qemu_get_be32s(f, depth);
+qemu_get_be32s(f, (uint32_t *)depth);
This is almost certainly the wrong way to fix this.
Paul
Hi everyone,
Here comes a list of outstanding qemu patches. These patches were all
posted or resent the last 10 days. Some of them are duplicates and
some are probably wrong. I'm sure there are even some patches hiding
in the archives that I've missed, but it's at least a good start.
Please let
andrzej zaborowski, le Fri 30 Nov 2007 15:30:40 +0100, a écrit :
I'm not sure why you get a warning here and I'm unable to run a build
at the moment. A void * should be able to store some (unknown size)
integer regardless of the platform.
No exactly. On 32bit platforms, void * are 32bits and
On 11/30/07, Carlo Marcelo Arenas Belon [EMAIL PROTECTED] wrote:
On Fri, Nov 30, 2007 at 02:36:32PM +0900, Magnus Damm wrote:
On Nov 19, 2007 6:18 AM, Carlo Marcelo Arenas Belon
[EMAIL PROTECTED] wrote:
The following patch changes the formatting string from %08x to
TARGET_FMT_plx
to
On 11/28/07, TeLeMan [EMAIL PROTECTED] wrote:
dyngen_code() can generate more than CODE_GEN_MAX_SIZE bytes, code_gen_buffer
can be overflowed. I hope this security bug will be fixed soon.
Thank you for the analysis. It's true that cpu_gen_code does not pass
CODE_GEN_MAX_SIZE (65536) on to
The pkgsrc build system has several patches against qemu 0.9.0.
They are at:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/emulators/qemu/patches/
Do you want them submitted in a certain way?
On Fri, Nov 30, 2007 at 04:28:09PM +, Paul Brook wrote:
On Friday 30 November 2007, Carlo Marcelo Arenas Belon wrote:
The following patch enforces that the sh4 target is 32 bit to prevent qemu
to expand incorrectly to a 64 bit wide cpu if compiled in a 64 bit host.
This is wrong. As
On Friday 30 November 2007, Blue Swirl wrote:
On 11/30/07, Jeremy C. Reed [EMAIL PROTECTED] wrote:
On Fri, 30 Nov 2007, Jeremy C. Reed wrote:
The pkgsrc build system has several patches against qemu 0.9.0.
They are at:
What is current situation with Host ARM and guest X86?
Should work with a bit of hacking.
Of course it's not likely to be particularly fast, even on relatively high-end
xscale hardware.
Paul
36 matches
Mail list logo
