CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer 07/03/21 08:21:02
Modified files:
target-ppc : op.c op_helper.h
Log message:
Fix compilation on 32 bits hosts (pb reported by Thiemo Seufer)
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qem
make[1]: Entering directory `/home/hys545/qemu/ppc64-softmmu'
gcc32 -g -o qemu-system-ppc64 vl.o osdep.o readline.o monitor.o pci.o
console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o
block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o
block-vpc.o block-vv
On Wednesday, March 21, 2007, 7:13:16, James Jacobs wrote:
> Suggested fix: support Win98SE. Is there a good technical reason why it
> can't be supported?
System obsolescence? Completely different kernel driver model compared to NT?
> * Also, \\.\kqemu is not a legal pathname under any version o
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/03/21 11:04:42
Modified files:
target-mips: mips-defs.h translate.c translate_init.c
Log message:
Move mips CPU specific initialization to translate_init.c.
CVSWeb URLs:
http://cvs.savan
Hi,
On Wed, 21 Mar 2007, James Jacobs wrote:
> It is not mentioned that KQEMU is incompatible with Win98SE.
>
> Suggested fix: support Win98SE.
Patches, please?
Ciao,
Dscho
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/
On 21 Mar 2007, at 06:13, James Jacobs wrote:
It is not mentioned that KQEMU is incompatible with Win98SE.
It is also not mentioned that it is incompatible with Linux 0.1.
However, if you make a closed world assumption (things which are not
stated to be true are false), this is easy to infe
Hi,
I have noticed that the condition table in target-sparc/translate.c is
wrong wrt ba and bnr, they are reversed. The emulation is still correct
as they are currently not used (do_branch() has two cases to handle
them). However I think it is a good idea to fix that, as they may be
used at some
Hi all,
I have noticed that the branches have some problem on the sparc target
in very rare conditions. This happens when a store double instruction
(std) is used in the delay slot, as in the following test:
tst %g0
bne 9b5d8
std %o2, [ %o1 ]
Inserting a nop between bne and std "fixes"
On Wed, 21 Mar 2007, Kirill A. Shutemov wrote:
Primarily, I also thought that problem is in padding, because, without the
patch F_GETLK, on 32-bit target recognises as F_GETLK64 on 64-bit host.
It's happen because on 64-bit host and 32-bit target F_GETLK == F_GETLK64 ==
TARGET_F_GETLK. So if you
On Tue, 20 Mar 2007, Paul Brook wrote:
Now that the dust has settled, I see where the change is probably a
no-op anyway. A quick little test program indicates that on x86_64,
l_start will have an offset of 8 wether the structure is packed or not,
and wether the __pad member is present or not. Th
On Mon, Mar 19, 2007 at 10:16:13PM +, Philip Boulain wrote:
> On 19 Mar 2007, at 20:23, Derek Fawcus wrote:
> > There was just a discussion relating to this on the darwin-kernel
> > list,
> > you may wish to review the archive.
> >
> > (The thread starts at http://lists.apple.com/archives/Dar
On 21 Mar 2007, at 15:39, Derek Fawcus wrote:
Well, they seemed to be suggesting that the kernel importing and
locking
the user space memory was a bit dodgy, and that the kernel should
export
memory to user space. Or maybe that only really applies in the
case of
devices...
Yes. It's p
I have noticed that the branches have some problem on the sparc target
in very rare conditions. This happens when a store double instruction
(std) is used in the delay slot, as in the following test:
tst %g0
bne 9b5d8
std %o2, [ %o1 ]
Inserting a nop between bne and std "fixes" the prob
I have noticed that the condition table in target-sparc/translate.c is
wrong wrt ba and bnr, they are reversed. The emulation is still correct
as they are currently not used (do_branch() has two cases to handle
them). However I think it is a good idea to fix that, as they may be
used at some point
On Wed, Mar 21, 2007 at 07:42:20PM +0100, Blue Swirl wrote:
> >I have noticed that the branches have some problem on the sparc target
> >in very rare conditions. This happens when a store double instruction
> >(std) is used in the delay slot, as in the following test:
> >
> > tst %g0
> > bne 9b
From my tests, it seems that std in a delayed branch slot occurs a
hundred of time during a boot, so not a lot. Adding a new field to the
CPU structure would probably decrease the performances (except on
hosts with a lot of registers). Therefore I am proposing something like
that (currently for st
Blue Swirl a écrit :
>>From my tests, it seems that std in a delayed branch slot occurs a
>> hundred of time during a boot, so not a lot. Adding a new field to the
>> CPU structure would probably decrease the performances (except on
>> hosts with a lot of registers). Therefore I am proposing someth
On Wed, Mar 21, 2007 at 09:34:46PM +0100, Aurelien Jarno wrote:
> Blue Swirl a écrit :
> >>From my tests, it seems that std in a delayed branch slot occurs a
> >> hundred of time during a boot, so not a lot. Adding a new field to the
> >> CPU structure would probably decrease the performances (exce
Like the semaphore patch a couple of days ago, this patch completes the
implementation of the message queue syscalls. With this patch, most
of the message queue tests in LTP now pass in the guest. The remaining
ones will require fixes in other syscall to fix, or at least eliminate
the noise to id
19 matches
Mail list logo
