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 fi
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 ta
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
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
Hi,
I note that there's a lot of recent progress on the USB side of things.
This is great.
Just thought I'd mention that it would be very useful to have the
USB support be more persistent, in the case where the device itself
resets, and appears to have been unplugged and replugged.
This happens
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
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
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 PROTE
> > 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
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 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:
http://cvs.savannah.gnu.org/view
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
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: /sources/qemu/qemu/target-sh4/cpu.h,v
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 a
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_
> 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 tar
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
> c
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 e
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 h
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:
Sent: Wednesday, November 28, 2007 10:28 AM
Subject: Re : [Qemu-devel] anoth
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 y
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
>
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
> > 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;
> > +
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 submitte
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
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 m
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
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.
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:
> > >
> > > http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc
> 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
37 matches
Mail list logo
