Hi,
On 12/12/2007, Armin <[EMAIL PROTECTED]> wrote:
> Here is an attempt to add PXA27x keypad support. It currently only
> supports the matrix type interface. It still needs direct and
> mulitswitch support added.
>
> Just wanted to get something out there for folks to pound on.
>
> Comment and fe
Robert Reif wrote:
Characters written to serial port A are not reliably making it to the
screen.
Turning on serial debugging shows that the characters are written to the
serial port. The characters do make it to the screen when debugging.
The problem seems to be caused by multiple streams o
Trying to build the current CVS Head with Mingw under windows, the result is
the following error message:
In file included from tap-win32.c:31:
sysemu.h:125: error: syntax error before ';' token
sysemu.h:137: error: syntax error before ',' token
sysemu.h:138: error: syntax error before ')' token
This patch adds documentation for the QEMU_STRACE environment setting.
Index: qemu/qemu-doc.texi
===
--- qemu.orig/qemu-doc.texi 2007-12-11 19:00:53.0 -0700
+++ qemu/qemu-doc.texi 2007-12-11 19:16:28.0 -0700
@@ -2437,6
Robert Reif wrote:
The problem I'm having is with sparc32 using a sun openboot image in
nographics mode where the prom uses serial port A as the system console.
The serial port output shows up in the host terminal window that qemu
was started in.
Characters written to serial port A are not reli
This is the mainstone II keypad support for alpha numeric keypad.
excludes the multiswitch and rotatory switch support
Needs "[Patch 1/2][PXA27x] initial keypad support" patch in order to work
- Armin
Index: qemu/hw/mainstone.c
===
Hello,
Please consider this for inclusion
Here is an attempt to add PXA27x keypad support. It currently only
supports the matrix type interface. It still needs direct and
mulitswitch support added.
Just wanted to get something out there for folks to pound on.
Comment and feedback welcome.
-
Rusty Russell wrote:
On Sunday 09 December 2007 09:02:48 Anthony Liguori wrote:
If QEMU ever got true SMP support, then virtio would not work as it
requires 16-bit atomic writes which AFAIK is not possible on a number of
non-x86 architectures.
Hmm? Where is this requirement coming fro
On Wednesday 12 December 2007, Thayne Harbaugh wrote:
> I believe Paul Brook did the original patch for arm eabi TLS. The patch
> has bounced around for a bit but hasn't been applied. We've been using
> this patch for a while and have tweaked it to be a bit more correct as
> far as code organizat
On Sunday 09 December 2007 09:02:48 Anthony Liguori wrote:
> If QEMU ever got true SMP support, then virtio would not work as it
> requires 16-bit atomic writes which AFAIK is not possible on a number of
> non-x86 architectures.
Hmm? Where is this requirement coming from?
I think everyone should
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski 07/12/12 01:16:24
Modified files:
. : cpu-all.h exec.c
linux-user : mmap.c
Log message:
Mark host pages as reserved (Magnus Damm).
CVSWeb URLs:
http://cvs.savanna
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski 07/12/12 01:11:43
Modified files:
hw : sh.h sh7750.c sh_timer.c
Log message:
Adds interrupt support to the sh specific timer code (Magnus Damm).
CVSWeb URLs:
http://cvs.savanna
Blue Swirl wrote:
On 12/10/07, Robert Reif <[EMAIL PROTECTED]> wrote:
Writing data to a serial port on the sparc emulation happens immediately.
I would like to throttle the write speed to match the actual baud rate.
What's the best way to do this in qemu? Will QEMUTimer work for a
1 millise
This futimesat() patch for linux-user was never applied.
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-11-20 21:02:40.0 -0700
+++ qemu/linux-user/syscall.c 2007-11-20 21:03:59.0 -0700
@@ -
I believe Paul Brook did the original patch for arm eabi TLS. The patch
has bounced around for a bit but hasn't been applied. We've been using
this patch for a while and have tweaked it to be a bit more correct as
far as code organization.
Please let me know what else should be improved for this
The EFAULT changes use a result of NULL to detect a failure from lock*()
functions. There are syscalls that accept NULL as a valid argument and
now the syscalls return -EFAULT. These patches allow appropriate
syscalls to accept NULL.
I have put together a regression test harness wrapped around t
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski 07/12/12 00:40:25
Modified files:
hw : sh_serial.c
linux-user : syscall.c
Log message:
sh_serial: enable tx after reset (Magnus Damm).
CVSWeb URLs:
http://cvs.sava
On 30/11/2007, Stefan Weil <[EMAIL PROTECTED]> wrote:
> 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.
Please check that you can still reproduce the error. pbrook explains
that tb->size cannot be zero unless there's
The linux-user qemu help usage doesn't output the default cpu_model in
the usage. This patch is a minimal code change to output the default
cpu_model.
Index: qemu/linux-user/main.c
===
--- qemu.orig/linux-user/main.c 2007-12-11 16:14:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski 07/12/11 23:23:52
Modified files:
. : vl.c
linux-user : syscall.c
Log message:
Add missing break just before execve, by Takashi Yoshii.
Fix a comment typo.
On Tuesday 11 December 2007, andrzej zaborowski wrote:
> On 10/12/2007, Balazs Attila-Mihaly (Cd-MaN) <[EMAIL PROTECTED]> wrote:
> > Here goes v0.2 for my patch :-)
> > Changes
> > - now the option is a separate command line switch:
> > -net capture,vlan=2,file=test.pcap
> > - it is also availabl
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski 07/12/11 22:31:32
Modified files:
. : vnc.c
Log message:
Fix fragments due to incomplete dirty tracking in CGA mode (Anthony
Liguori).
CVSWeb URLs:
http://cvs.savannah.gnu.or
On 10/12/2007, Balazs Attila-Mihaly (Cd-MaN) <[EMAIL PROTECTED]> wrote:
> Here goes v0.2 for my patch :-)
> Changes
> - now the option is a separate command line switch:
> -net capture,vlan=2,file=test.pcap
> - it is also available from the monitor
> - added some more constants / defines to avoid
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski 07/12/11 22:15:29
Modified files:
hw : ide.c
Log message:
IDE should send irq after WIN_DIAGNOSE (Tristan Gingold).
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski 07/12/11 21:56:43
Modified files:
. : qemu-doc.texi
Log message:
Update documention with '-drive' usage (Laurent Vivier).
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu
This patchset introduces SMBIOS/DMI table generation to qemu for PC machines.
The intial patch includes all changes needed to create the tables and load
them into memory. This patch depends on libuuid. The subsequent patches
detect for libuuid and optionally link to the library if present. The f
5 files changed, 749 insertions(+), 3 deletions(-)
Makefile.target |4
hw/pc.c | 45
smbios.c| 517 +++
smbios_types.h | 182 +++
sysemu.h|4
# HG changeset patch
# User Ryan Harper <[EMAIL
3 files changed, 38 insertions(+), 2 deletions(-)
Makefile.target |5 -
configure | 26 ++
smbios.c|9 -
# HG changeset patch
# User Ryan Harper <[EMAIL PROTECTED]>
# Date 1197402122 21600
# Node ID 115f40a4994be1d5b44ef193b3ccbe8e26410eef
3 files changed, 61 insertions(+), 6 deletions(-)
smbios.c | 58 --
sysemu.h |1 +
vl.c |8
# HG changeset patch
# User Ryan Harper <[EMAIL PROTECTED]>
# Date 1197402122 21600
# Node ID f1372e77455459b3e21ae908bb56cd43356
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/12/11 19:39:25
Modified files:
. : Makefile.target cpu-exec.c
target-sparc : op.c
Log message:
Partial fix to Sparc32 Linux host global register mangling problem
CVSWeb UR
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/12/11 19:35:45
Modified files:
. : cpu-exec.c exec-all.h exec.c translate-all.c
Log message:
Fix code generation buffer overflow reported by TeLeMan
CVSWeb URLs:
http://cvs.savannah.
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/12/11 19:33:21
Modified files:
pc-bios: README openbios-sparc32 openbios-sparc64
Log message:
Update OpenBIOS images to SVN revision 181. Changes:
r177:
Reset fixes:
The first patch (solaris-force32bit.diff) is a patch to allow an x86-64 Solaris
host
to compile a 32-bit version of qemu. This works because Solaris x86-64 can run
both 64-bit and 32-bit binaries.
The second patch is just a README for building on Solaris with a status of
the tools and libraries
Hi,
I found some instructions missing on SH4, and added some.
Graphics extentions(like sin/cos/sqrt/vector op) are still missing,
but I believe no one need them, at least, so far.
"fneg" is implemented as 32bit op, according to the programming manual.
/yoshii
diff -u -p -r1.10 op.c
--- a/target-
Small patch around execve again.
Now unlinkat() goes through into execve. Here is the fix.
/yoshii
diff -u -p -r1.157 syscall.c
--- a/linux-user/syscall.c 9 Dec 2007 23:12:55 - 1.157
+++ b/linux-user/syscall.c 11 Dec 2007 17:02:11 -
@@ -3177,6 +3176,7 @@ abi_long do_syscall
On Tue, Dec 11, 2007 at 10:49:05AM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Tue, Dec 11, 2007 at 09:48:22AM -0600, Anthony Liguori wrote:
> >
> >>Richard W.M. Jones wrote:
> >>
> >>Actually, this was the original intention of the -name parameter. What
> >>a management too
Daniel P. Berrange wrote:
On Tue, Dec 11, 2007 at 09:48:22AM -0600, Anthony Liguori wrote:
Richard W.M. Jones wrote:
Actually, this was the original intention of the -name parameter. What
a management tool would want to do is:
1) if -name is specified by user, generate one with uuidgen
2
Here's a patch to avoid processing NULL args in execve. It prevents
trying to dereference NULL.
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-11-19 20:45:20.0 -0700
+++ qemu/linux-user/syscall.c
Paul Brook wrote:
Why can't we make the monitor interface a "formal" interface?
Because then fixing a type or extending the interface becomes a pain.
It's also much more difficult to specify a text-base interface
completey, compared to a C api (where sometimes all you need is the
header
> > Why can't we make the monitor interface a "formal" interface?
>
> Because then fixing a type or extending the interface becomes a pain.
>
> It's also much more difficult to specify a text-base interface
> completey, compared to a C api (where sometimes all you need is the
> header and a few com
Daniel P. Berrange wrote:
On Tue, Dec 11, 2007 at 09:16:43AM +0200, Yuval Kashtan wrote:
- This is very useful when you want to manage and control QEMU, for instance
developing a GUI to attach and detach usb devices or controlling more than
one instance of QEMU from a single management point, re
Avi Kivity wrote:
libqemumonitor.so is an excellent idea. perhaps the libvirt code can be
used as a base?
We should also provide bindings to the saner languages that management
apps are typically written in.
Libvirt has most of the major languages covered now. The only language
I'm aware o
Anthony Liguori wrote:
Yuval Kashtan wrote:
As I can see,
There is HUGH interest in management API for QEMU.
seemly, DBus is NOT the right solution for direct integration into
QEMU as it is not cross platform enough, pose extra dependency and
(probably) not suitable for embedded systems.
Kee
Anthony Liguori wrote:
Richard W.M. Jones wrote:
> Anthony Liguori wrote:
>> Daniel P. Berrange wrote:
>>> Or have 2 monitor interaction modes. One mode uses the command line
>>> style
>>> suitable for people / scripting languages. The other umode ses a
>>> binary XDR
>>> protocol for serializin
On Tue, Dec 11, 2007 at 09:48:22AM -0600, Anthony Liguori wrote:
> Richard W.M. Jones wrote:
>
> Actually, this was the original intention of the -name parameter. What
> a management tool would want to do is:
>
> 1) if -name is specified by user, generate one with uuidgen
> 2) pass -name and -
Daniel P. Berrange wrote:
I think that many projects now want to control qemu programatically.
The monitor is not a good interface since it is text-based, hard to
parse, and liable to change without notice when new features are added.
However, I agree that having many similar constructs is
Richard W.M. Jones wrote:
Anthony Liguori wrote:
Daniel P. Berrange wrote:
Or have 2 monitor interaction modes. One mode uses the command line
style
suitable for people / scripting languages. The other umode ses a
binary XDR
protocol for serializing the args & returns values for formal contro
On Tue, Dec 11, 2007 at 09:16:43AM +0200, Yuval Kashtan wrote:
> - This is very useful when you want to manage and control QEMU, for instance
> developing a GUI to attach and detach usb devices or controlling more than
> one instance of QEMU from a single management point, receiving parameters
> ex
Anthony Liguori wrote:
Daniel P. Berrange wrote:
Or have 2 monitor interaction modes. One mode uses the command line style
suitable for people / scripting languages. The other umode ses a
binary XDR
protocol for serializing the args & returns values for formal control
APIs to use in a easy man
Yuval Kashtan wrote:
As I can see,
There is HUGH interest in management API for QEMU.
seemly, DBus is NOT the right solution for direct integration into
QEMU as it is not cross platform enough, pose extra dependency and
(probably) not suitable for embedded systems.
Keeping only the "old" moni
On Tue, Dec 11, 2007 at 05:21:08PM +0200, Yuval Kashtan wrote:
> As I can see,
> There is HUGH interest in management API for QEMU.
> seemly, DBus is NOT the right solution for direct integration into QEMU as
> it is not cross platform enough, pose extra dependency and (probably) not
> suitable for
On Tue, Dec 11, 2007 at 04:17:51PM +0100, Jean-Christian de Rivaz wrote:
> Anthony Liguori a écrit :
> > The main objection I have to dbus is that it's very heavy weight. It
> >implies a rather fat infrastructure and it not very suitable for
> >embedding. QEMU has very few dependencies and that
As I can see,
There is HUGH interest in management API for QEMU.
seemly, DBus is NOT the right solution for direct integration into QEMU as
it is not cross platform enough, pose extra dependency and (probably) not
suitable for embedded systems.
Keeping only the "old" monitor interface with no form
Anthony Liguori a écrit :
> The main objection I have to dbus is that it's very heavy weight. It
implies a rather fat infrastructure and it not very suitable for
embedding. QEMU has very few dependencies and that is a strength ATM.
People interested in embedding QEMU still want a good manage
Daniel P. Berrange wrote:
On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
Dor Laor wrote:
Laurent Vivier wrote:
Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
Hi,
Hi,
At this point I am not interested i
On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
> Dor Laor wrote:
> >Laurent Vivier wrote:
> >>Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
> >>
> >>>Hi,
> >>>
> >>
> >>Hi,
> >>
> >>
> >>>At this point I am not interested in integrating it into QEMU as
On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
> Dor Laor wrote:
> >Laurent Vivier wrote:
> >>Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
> >>
> >>>Hi,
> >>>
> >>
> >>Hi,
> >>
> >>
> >>>At this point I am not interested in integrating it into QEMU as
On Tue, Dec 11, 2007 at 01:05:38PM +0200, Avi Kivity wrote:
> Fabrice Bellard wrote:
> >Hi,
> >
> >At this point I am not interested in integrating it into QEMU as it is
> >one more API level to maintain in addition to the command line
> >monitor. However, I can change my mind if several projects
On Mon, Dec 10, 2007 at 10:28:01AM +0200, Yuval Kashtan wrote:
> Hello All,
> Attached is a proposed patch which adds DBus support to QEMU. DBus is a
> standard message bus for linux (
> http://www.freedesktop.org/wiki/Software/dbus )
> The idea behind this is to allow for external programs such as
Dor Laor wrote:
Laurent Vivier wrote:
Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
Hi,
Hi,
At this point I am not interested in integrating it into QEMU as it is
one more API level to maintain in addition to the command line monitor.
However, I can change m
Avi Kivity wrote:
Fabrice Bellard wrote:
Hi,
At this point I am not interested in integrating it into QEMU as it
is one more API level to maintain in addition to the command line
monitor. However, I can change my mind if several projects insists to
have a similar interface.
I think that
Hi,
this patch updates ppc_prep.c. It now uses qemu_ram_alloc.
The original purpose of this patch was being able to use a bios
bigger than 1MB. And updating ppc_prep.c
was a better way than increasing BIOS_SIZE.
Tristan.
qemu.diff
Description: Binary data
Hi,
this very simple patch allows to suppress the (virtual) mbr of block-
vvfat. Without an mbr, the fat filesystem
starts obviously at block 0. Some simple OS doesn't support mbr.
Tristan.
qemu.diff
Description: Binary data
Fabrice Bellard wrote:
Hi,
At this point I am not interested in integrating it into QEMU as it is
one more API level to maintain in addition to the command line
monitor. However, I can change my mind if several projects insists to
have a similar interface.
I think that many projects now w
Am 11.12.2007 um 11:29 schrieb Laurent Vivier:
Le mardi 11 décembre 2007 à 11:20 +0100, Andreas Färber a écrit :
Am 11.12.2007 um 10:23 schrieb Laurent Vivier:
perhaps the DBUS interface can replace the command line monitor ?
We have just to move the command line interface to a client speaki
Hello all,
First of all I want to apologize for this mail and hope that I won't wast to
much of your valuable time hacking on Qemu ;-). My goal is to implement a
tracing system in Qemu, which would suspend the emulation at certain points
(determined by linear addresses), dump some information f
Le mardi 11 décembre 2007 à 11:20 +0100, Andreas Färber a écrit :
> Am 11.12.2007 um 10:23 schrieb Laurent Vivier:
>
> > perhaps the DBUS interface can replace the command line monitor ?
> > We have just to move the command line interface to a client speaking
> > to
> > qemu through the DBUS int
Laurent Vivier kirjoitti:
Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
Hi,
Hi,
At this point I am not interested in integrating it into QEMU as it is
one more API level to maintain in addition to the command line monitor.
However, I can change my mind if several projec
Am 11.12.2007 um 10:23 schrieb Laurent Vivier:
perhaps the DBUS interface can replace the command line monitor ?
We have just to move the command line interface to a client speaking
to
qemu through the DBUS interface.
That would work for few platforms only!
Andreas
Laurent Vivier wrote:
Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
Hi,
Hi,
At this point I am not interested in integrating it into QEMU as it is
one more API level to maintain in addition to the command line monitor.
However, I can change my mind if several
Laurent Vivier wrote:
Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
Hi,
Hi,
At this point I am not interested in integrating it into QEMU as it is
one more API level to maintain in addition to the command line monitor.
However, I can change my mind if several projects in
Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
> Hi,
Hi,
> At this point I am not interested in integrating it into QEMU as it is
> one more API level to maintain in addition to the command line monitor.
> However, I can change my mind if several projects insists to have a
Magnus Damm wrote:
Hi everyone,
On Dec 5, 2007 5:45 PM, Magnus Damm <[EMAIL PROTECTED]> wrote:
Hi all,
This patch teaches the user space emulator about host pages. It marks
present host page mappings with PAGE_RESERVED so mmap_find_vma()
properly can detect that pages at mmap_next_start should
Hi,
At this point I am not interested in integrating it into QEMU as it is
one more API level to maintain in addition to the command line monitor.
However, I can change my mind if several projects insists to have a
similar interface.
Regards,
Fabrice.
Yuval Kashtan wrote:
Some answers:
-
Am 09.12.2007 um 17:52 schrieb Mike Kronenberg:
On the other hand, the QT implementation is and remains the fastest
solution, as no of the other allows directly accessing the video-
buffer, which results in way more copying.
Likely, QT doesn't come with it's own set of video drivers, but us
75 matches
Mail list logo
