I can set up a phpbb this week if someone wants.
On Nov 18, 2007 10:48 PM, Shaddy Baddah <[EMAIL PROTECTED]>
wrote:
> Ottavio Caruso wrote:
> > has anybody got any news on when the Qemu Forum will be up again?
> >
>
> I'd like to second the call for its return. At least can the archive be
> retai
On Mon, Nov 19 2007, Juergen Lock wrote:
> Oops, I seem to have missed this post, sorry for not answering earlier...
>
> In article <[EMAIL PROTECTED]> you write:
> >On Tue, Nov 13 2007, Juergen Lock wrote:
> >> Hi!
> >>
> >> Yesterday I learned that FreeBSD 7.0-BETA2 guests will no longer
> >>
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/11/19 11:39:30
Modified files:
target-ppc : op_mem.h translate.c
Log message:
PowerPC instruction fixes:
- hrfid is part of the hypervisor extension
- fix stfiwx naming
CVSWe
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/11/19 11:41:10
Modified files:
target-ppc : cpu.h helper.c translate_init.c
Log message:
PowerPC 620 MMU do not have the same exact behavior as standard
64 bits PowerPC ones.
CVSWe
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/11/19 13:22:47
Modified files:
target-ppc : cpu.h translate_init.c
Log message:
Remove shared macro used to define PowerPC implementations instructions
sets:
tend more to propagate
There is error in execve syscall implementation. guest_argp and guest_envp
should not be altered during argument list checking.
This bug was introduced by commit "suppressed tgetx and tputx (initial
patch by Thayne Harbaugh)".
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index f08ba
Hi,
Qemu currently uses 6 65k tables of pointers for handling ioports, which
makes 3MB on 64bit machines. There's a comment that says "XXX: use a two
level table to limit memory usage". But wouldn't it be more simple and
effective to just allocate them through mmap() and when a NULL pointer
is rea
Samuel Thibault, le Mon 19 Nov 2007 15:20:16 +, a écrit :
> Qemu currently uses 6 65k tables of pointers for handling ioports, which
> makes 3MB on 64bit machines. There's a comment that says "XXX: use a two
> level table to limit memory usage". But wouldn't it be more simple and
> effective to
The attached patch drops a variable that became useless.
Samuel
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.369
diff -u -p -r1.369 vl.c
--- vl.c19 Nov 2007 01:05:22 - 1.369
+++ vl.c
hi,
this patch make it possible to define from the command line a static
devfn value for each pci
device.
it was wrote for addressing a problem that right now qemu devices get
their devfn in random way
(almost random)
the problem with this is that with adding and removing devices some
devfn v
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/11/19 16:10:33
Modified files:
target-mips: translate_init.c
Log message:
Add older 4Km variants.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsro
On Monday 19 November 2007, Samuel Thibault wrote:
> Samuel Thibault, le Mon 19 Nov 2007 15:20:16 +, a écrit :
> > Qemu currently uses 6 65k tables of pointers for handling ioports, which
> > makes 3MB on 64bit machines. There's a comment that says "XXX: use a two
> > level table to limit memor
Paul Brook, le Mon 19 Nov 2007 16:17:26 +, a écrit :
> On Monday 19 November 2007, Samuel Thibault wrote:
> > Samuel Thibault, le Mon 19 Nov 2007 15:20:16 +, a écrit :
> > > Qemu currently uses 6 65k tables of pointers for handling ioports, which
> > > makes 3MB on 64bit machines. There's a
Izik Eidus wrote:
hi,
this patch make it possible to define from the command line a static
devfn value for each pci
device.
it was wrote for addressing a problem that right now qemu devices get
their devfn in random way
(almost random)
the problem with this is that with adding and removing de
On Mon, 2007-11-19 at 18:53 +0200, Izik Eidus wrote:
> Izik Eidus wrote:
> > hi,
> > this patch make it possible to define from the command line a static
> > devfn value for each pci
> > device.
> > it was wrote for addressing a problem that right now qemu devices get
> > their devfn in random w
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/11/19 19:14:10
Modified files:
target-sparc : op_helper.c
Log message:
Fix MXCC register 64 bit read word order (Robert Reif)
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/
On 11/18/07, Robert Reif <[EMAIL PROTECTED]> wrote:
> Blue Swirl wrote:
>
> >On 11/16/07, Robert Reif <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>This patch fixes the word order for 64 bit reads of the mxcc registers.
> >>>
> >>>
> >
> >Otherwise everything seems OK, but it breaks NetBSD version 3 on S
This patch adds support for some more MMU registers:
0x10 TLB replacement control
0x13 read/write access to 0x03 SFSR
0x14 read/write access to 0x04 SFAR
Only support for 1 real register was added (0x10) but 16 were added
to CPUSPARCState because we don't check for invalid register
The patch that's attached contains a fix that prevents qemu-img from compiling
on Windows under cygwin. It also contains a patch to the old and probably
unused cocoa file as well as some include fixes for monitor.c and adlib.c .
diffFromHead.diff
Description: Binary data
Hello,
I'm using qemu-ppc 0.9.0 running under windows x86 host connected via tap or
2 instances of QEMU connected via socket connection. Guest is ppc linux
(both 2.4 and 2.6 kernels). When any of processes running on QEMU linux
reaches 100% guest CPU consumption (50% on 2 core host) network
commun
20 matches
Mail list logo