Attached is a refreshed patch w/ a couple of additional fixes. This
patch provides an implementation of semaphore interfaces (semget(),
semctl(), semop()) that consists mostly of the structure mapping
needed for 32 bit guest on 64 host such as arm on x86_64.
S
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/03/23 00:43:28
Modified files:
target-mips: cpu.h exec.h op.c op_helper.c translate.c
Log message:
Fix enough FPU/R2 support to get 24Kf going.
CVSWeb URLs:
http://cvs.savannah.gnu.org/v
Hi,
On Thu, 22 Mar 2007, Julian Seward wrote:
> On Thursday 22 March 2007 23:27, Paul Brook wrote:
> > > Do you mean you're asking me to break up Paul Brook's QOPS tree at
> > > https://nowt.dyndns.org and submit it to mainline? I can do this thing,
> > > if you really think it would help.
> >
>
On Thursday 22 March 2007 23:57, Julian Seward wrote:
> On Thursday 22 March 2007 23:27, Paul Brook wrote:
> > > Do you mean you're asking me to break up Paul Brook's QOPS tree at
> > > https://nowt.dyndns.org and submit it to mainline? I can do this
> > > thing, if you really think it would help.
Hi all,
The patch below adds support for taddcc, taddcctv, tsubcc and tsubcctv
that were treated as illegal instructions. With them, the SPARC V8
instruction set is now fully implemented.
Bye,
Aurelien
Index: target-sparc/cpu.h
==
On Thursday 22 March 2007 23:27, Paul Brook wrote:
> > Do you mean you're asking me to break up Paul Brook's QOPS tree at
> > https://nowt.dyndns.org and submit it to mainline? I can do this thing,
> > if you really think it would help.
>
> If you implement all the missing bits in the process it'l
On Thursday 22 March 2007 7:29 pm, Thiemo Seufer wrote:
> > Do you mean you're asking me to break up Paul Brook's QOPS tree at
> > https://nowt.dyndns.org and submit it to mainline? I can do this thing,
if
> > you really think it would help. Seems a bit roundabout to submit Paul
> > Brook's w
Rob Landley wrote:
> On Thursday 22 March 2007 7:00 pm, Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 22 Mar 2007, Rob Landley wrote:
> >
> > > On Tuesday 20 March 2007 6:19 pm, Julian Seward wrote:
> > > > Limited effort is always a problem, granted.
> > > >
> > > > So here's a broader que
> Do you mean you're asking me to break up Paul Brook's QOPS tree at
> https://nowt.dyndns.org and submit it to mainline? I can do this thing, if
> you really think it would help.
If you implement all the missing bits in the process it'll help ;-)
Paul
_
On Thursday 22 March 2007 7:00 pm, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 22 Mar 2007, Rob Landley wrote:
>
> > On Tuesday 20 March 2007 6:19 pm, Julian Seward wrote:
> > > Limited effort is always a problem, granted.
> > >
> > > So here's a broader question, which I'm surprised nobody has
Hi,
On Thu, 22 Mar 2007, Rob Landley wrote:
> On Tuesday 20 March 2007 6:19 pm, Julian Seward wrote:
> > Limited effort is always a problem, granted.
> >
> > So here's a broader question, which I'm surprised nobody has asked
> > before (afaik). Think forward to a hypothetical QEMU 1.0 release.
On Thu, 2007-03-22 at 18:46 -0400, Rob Landley wrote:
> On Tuesday 20 March 2007 6:11 pm, Jocelyn Mayer wrote:
> > Log message:
> > PowerPC 2.03 SPE extension - first pass.
>
> QEMU supports the Cell processor now? How would one go about testing this?
I guess you will be disapointed:
SPE ext
Hi Rob,
On Thu, 22 Mar 2007, Rob Landley wrote:
> On Tuesday 20 March 2007 6:11 pm, Jocelyn Mayer wrote:
> > Log message:
> > PowerPC 2.03 SPE extension - first pass.
>
> QEMU supports the Cell processor now? How would one go about testing this?
AFAIR Linux gained official Cell support rec
On Tuesday 20 March 2007 6:19 pm, Julian Seward wrote:
> Limited effort is always a problem, granted.
>
> So here's a broader question, which I'm surprised nobody has asked
> before (afaik). Think forward to a hypothetical QEMU 1.0 release.
> What criteria are required for such a release?
*cough
On Tuesday 20 March 2007 6:11 pm, Jocelyn Mayer wrote:
> Log message:
> PowerPC 2.03 SPE extension - first pass.
QEMU supports the Cell processor now? How would one go about testing this?
Rob
--
Vista: Windows Millenium Second Edition
___
Qemu
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/03/22 22:41:50
Modified files:
target-ppc : cpu.h op.c translate.c
Log message:
PowerPC improvments:
- add missing 64 bits rotate instructions
- safely define TARGET_PPCSPE wh
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/03/22 22:17:08
Modified files:
target-ppc : exec.h op.c op_helper.c op_helper.h translate.c
Log message:
PowerPC bugfixes:
- must clear carry bit when doing addic with a zero immediat
With a little help from Paul yesterday, I was able to come up with a
scheme for detecting bad pointers passed to system calls in linux-user
mode. This is used to return EFAULT as would be done on a real kernel.
The attached patch is very preliminary, but shows how it can be done.
I'm sending it
Blue Swirl a écrit :
> Hi,
>
> I can't reproduce the problem with attached test program. Also the generated
> ops look just fine:
>
[snip]
>
> Can you describe how to reproduce the bug?
>
Well I also have difficulties to reproduce it with a simple program. I
have detected it while trying to
Hi,
could SPARC or PPC users please check whether the timer code
in hw/m48t59.c is really correct?
I expect a crash in qemu_mod_timer after wd_timer = NULL and
a call to qemu_mod_timer with this NULL value.
The same applies to alrm_timer.
I wrote a quick-and-dirty patch, but think that even mor
Thomas Orgis wrote:
Am Sun, 18 Mar 2007 09:18:40 +
schrieb Nigel Horne <[EMAIL PROTECTED]>:
The first part is true, the second is not, in that I already upgraded
to the 686 kernel, so the qemu build on FC6 is not fixed by installing the 686
kernel.
So, do we have any other clue
Am Sun, 18 Mar 2007 09:18:40 +
schrieb Nigel Horne <[EMAIL PROTECTED]>:
> The first part is true, the second is not, in that I already upgraded
> to the 686 kernel, so the qemu build on FC6 is not fixed by installing the
> 686 kernel.
So, do we have any other clue about this?
Some qemu code
Hi,
I can't reproduce the problem with attached test program. Also the generated
ops look just fine:
IN:
0x00010074: sethi %hi(0x2), %g3
0x00010078: or %g3, 0xa0, %g3 ! 0x200a0
0x0001007c: mov -1, %g1
0x00010080: mov -1, %g2
0x00010084: tst %g0
0x00010088: bne 0x10094
0x0001008
On Thu, 2007-03-22 at 12:39 -0500, Jason Wessel wrote:
> Attached is a patch as well as an example program, where I took the code
> from the from the linux kernel and made a call in with a dummy packet.
>
> It appears the problem is the addic translation does not correctly
> set/reset the carry
Has anyone succeeded in booting a Linux 2.6 kernel on Qemu PPC? If so,
what distribution did you use?
Thanks,
--Ed
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Attached is a patch as well as an example program, where I took the code
from the from the linux kernel and made a call in with a dummy packet.
It appears the problem is the addic translation does not correctly
set/reset the carry bit, and this is a regression vs the source base on
3/7/2007.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/03/22 15:08:55
Modified files:
linux-user : syscall.c
Log message:
Fix fcntl64 logic bug, by Kirill A. Shutemov.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.
On [Tue, 20.03.2007 13:42], Kirill A. Shutemov wrote:
> Yep. You're right. Fixed patch in the attachment.
>
Patch that fixes dummy bug in the attachment. Sorry.
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
I ran ./configure again, and it' OK now.
Thanks.
Selon Anthony Liguori <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
> > I have exactly the same error, using MinGW.
> >
> > I commented out the faulty line in vl.c, and compiled again. Now, I have
> > following error :
> >
> > C:/msys/home/Deni
[EMAIL PROTECTED] wrote:
I have exactly the same error, using MinGW.
I commented out the faulty line in vl.c, and compiled again. Now, I have
following error :
C:/msys/home/Denis/qemu/hw/pckbd.c:376: undefined reference to `vmmouse_init'
make[1]: *** [qemu.exe] Error 1
make[1]: Leaving director
[EMAIL PROTECTED] wrote:
> I have exactly the same error, using MinGW.
>
> I commented out the faulty line in vl.c, and compiled again. Now, I have
> following error :
Win32 appears to have no straight replacement for lockf, so I disabled
pidfile locking there for now.
> C:/msys/home/Denis/qemu/
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/03/22 12:36:53
Modified files:
. : vl.c
Log message:
Win32 build fix. FIXME: This disables locking of the pidfile, a
Win32 replacement of lockf should be used here.
CVSW
Patch to sync arm syscall numbers with 2.6.21-rc4 in the attachment.
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/
diff --git a/qemu/linux-user/arm/syscall_nr.h b/qemu/linux-user/arm/syscall_nr.h
index c48be98
I have exactly the same error, using MinGW.
I commented out the faulty line in vl.c, and compiled again. Now, I have
following error :
C:/msys/home/Denis/qemu/hw/pckbd.c:376: undefined reference to `vmmouse_init'
make[1]: *** [qemu.exe] Error 1
make[1]: Leaving directory `/home/Denis/qemu/i386-so
use mingw to compile qemu for windows hosts, not cygwin.
if I recall well, SDL does not cope well on cygwin.
--
Christian
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
U qemu/slirp/tcp_input.c
U qemu/slirp/tcp_output.c
U qemu/slirp/tcp_subr.c
U qemu/slirp/tcp_timer.c
U qemu/slirp/tcp_timer.h
U qemu/slirp/tcp_var.h
U qemu/slirp/tcpip.h
U qemu/slirp/tftp.c
U qemu/slirp/tftp.h
U qemu/slirp/udp.c
U qemu/slirp/udp.h
cvs checkout: Updating qemu/target-arm
U qemu/target
36 matches
Mail list logo
