CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/04/09 22:45:36
Modified files:
. : cpu-exec.c vl.h
hw : openpic.c ppc.c ppc_chrp.c ppc_prep.c
target-ppc : cpu.h helper.c translate_init.c
Log message:
On Mon, 2007-04-09 at 17:26 -0400, Rob Landley wrote:
> On Sunday 08 April 2007 7:19 pm, Paul Brook wrote:
[...]
> > AFAIK PPC emulation hasn't *ever* worked well enough to boot without at
> least
> > building a custom linux kernel. In addition the -kernel commandline option
> > have no effect
Yu, Xiaoyang wrote:
>
>
> The USB problem I met is that using some kind of USB disks will cause
> guest OS run extremely slow, while these disks can work properly in host
> OS. It looks like the USB simulation in QEMU is not fully featured, and
> can not handle some error conditions properly.
>
On Sunday 08 April 2007 7:19 pm, Paul Brook wrote:
> > Mr Paul Brook did break the PREP and heathrow machines while doing
> > changes in the PCI code. There were some posts on this list reporting
> > this and he never even tried to fix what he broke. And now he's
> > complaining "I cannot test as i
On Sunday 08 April 2007 4:43 pm, Natalia Portillo wrote:
> Hi all,
>
> I have a huge list of operating systems (both closed and open source, that
> works and that doesn't work under QEMU) that can be used to check that QEMU
> doesn't broke (or even, that it corrects a non-working state).
I vaguel
Ok this is the fix I came up with.
Basically it will check all the other objects that could potentially be
waiting for service. This will prevent one high priority object from
starving the rest.
I'm not certain what the intention for the timeout > 0 check but this
completely prevented any wait
Ok I located the source of the problem.
The code in main_loop_wait() that uses WaitForMultipleObjects will only
service one object that woke it up.
What is occuring is that the host_alarm timer is being serviced anytime
the tap_semaphore is also signaled, therefore the tap callback function is
> > In its current implementation it doesn't provide any functional
> > enhancements over a {callpack, opaque, nIRQ} triplet. What it does do is
> > isolate the device (IRQ source) emulation from the implementation
> > details.
>
> So, I was confused by some remarks saying that this would give new
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/04/09 15:14:57
Modified files:
. : disas.c
Log message:
Fix monitor disasm output for Sparc64 target
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/disas.c?cvsroot=qemu&r1=1.36
On Mon, 2007-04-09 at 14:58 +0100, Paul Brook wrote:
[...]
> > > Having each device keep track of 3 values (callback, opaque and nIRQ; see
> > > earlier) is a real mess, evidenced by the fact that devices don't do this
> > > consistently, the PCI code has grown its own slightly different
> > > mec
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/04/09 14:17:31
Modified files:
target-mips: op.c translate.c
Log message:
Fix CP0_IntCtl handling.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/04/09 14:16:30
Modified files:
target-mips: op.c
Log message:
Proper handling of reserved bits in the context register.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/04/09 14:15:41
Modified files:
target-mips: op.c translate.c
Log message:
Mark watchpoint features as unimplemented.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/04/09 14:14:21
Modified files:
target-mips: op_mem.c translate.c
Log message:
Catch unaligned sc/scd.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_mem.c?cvsroot=q
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/04/09 14:13:40
Modified files:
target-mips: op.c translate.c
Log message:
Fix exception handling cornercase for rdhwr.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/o
> > In summary the IRQ source (ie. device raising the IRQ) needs to keep
> > track of 4 values:
> > 1) Callback
> > 2) Opaque callback argument
> > 3) PIN number
> > 4) IRQ state.
>...
> > I believe (1) and (2) are inherently linked, and it makes no sense to
> > set/change them individually.
>
> OK
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/04/09 12:31:31
Modified files:
target-mips: translate.c
Log message:
Remove bogus mtc0 handling.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qem
On Mon, 2007-04-09 at 01:41 +0100, Paul Brook wrote:
> [replying to a couple of different mails]
>
> > What do you need to route an IRQ ?
> > -> A peripheral destination
>
> Agreed.
>
> > What we got now ?
> > -> a callback with 3 parameters: an opaque, a PIN (the n_IRQ) and a
> > state
>
> We
On Mon, 2007-04-09 at 00:19 +0100, Paul Brook wrote:
> > Mr Paul Brook did break the PREP and heathrow machines while doing
> > changes in the PCI code. There were some posts on this list reporting
> > this and he never even tried to fix what he broke. And now he's
> > complaining "I cannot test as
Sorry, I'm afraid I badly mixed up things in my mind.
vncrec and pyvnc2swf record VNC server responses, not client actions, so
they will hardly be of any help.
To record and replay client actions these tools are more appropriate:
http://cyberelk.net/tim/rfbproxy/
http://cyberelk.net/tim/rfbplay
Possibly it's only a starting point but I could use
the files found at
http://www.pps.jussieu.fr/~letouzey/emul_debianppc.en.html
to actually see I could boot some linux on qemu-system-ppc.
Skipping the part aboud vde, I could boot it both with
0.9.0 and with a snapshot dated 20070406.
From the
21 matches
Mail list logo
