> QEMU does not set the Thumb bit when reading from R15 in Thumb mode.
Neither does real hardware.
Paul
Hi,
On 29/06/07, Botond Kardos <[EMAIL PROTECTED]> wrote:
Hi,
thanks to Andrzej Zaborowski there's now a PXA270 based machine (or
more precisely 4 machines) in the development branch. Did anybody manage
to try it out? Is there a test image prepared for the PXA270
environment? I've tried
[EMAIL PROTECTED] said:
>> The following patch fixes the "-h" segfault, and also appears to yield
>> the exit value intended by previous folks.
>
> Thanks, I committed a fix which I hope is better.
Yes, good patch. More thorough. Thanks for the note.
Marion
DetaolB aimed to be a "much-less-than-a-floppy" x86 linux live distro.
Now, it's evolving more into "a-la-slax" type of distro.
DetaolB v0.4 has been released 29th,June 2007 on sf.net
=>
http://sourceforge.net/project/showfiles.php?group_id=140321&package_id=155481&release_id=519786
Mailing lis
Marion Hakanson wrote:
> When you run "qemu -h", help() is called with optarg==NULL, which
> causes a segfault on my system (Solaris-10U3_x86, 64-bit kernel,
> but qemu compiled as 32-bit app, gcc-3.4.5 from blastwave.org).
> It's a side-effect of the -r1.315 patch which fixed related segfaults.
>
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/06/29 23:26:08
Modified files:
. : vl.c
Log message:
Sanitize exit codes of help queries, this time for real.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=
I starting trying the qemu PPC system emulation for the 405 boards and
ran into an issue with where the board info pointer is located in
memory. The first Linux MMU entry only covers the first few megs of RAM
and the current code puts the bdloc at the very top of memory. And when
the kernel tries t
On [Tue, 26.06.2007 00:04], Kirill A. Shutemov wrote:
> On success, getgroups() returns the number of supplementary group IDs. So,
> we can swap real number group IDs.
>
> Patch in the attachment.
It's trivial. Can anybody commit?
--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LL
> > I'd expect the overhead of SIGSEGV+mmap to be prohibitive. I don't have
> > numbers to back this up, but experience with MIPS system emulation shows
> > that TLB miss cost can have significant effect on overall performance.
>
> I'd say this can't be worse than on MacOS X where Mach exception
>
Blue Swirl wrote:
On 6/29/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
In fact, running in 64 bit is not necessary : It is simpler and more
efficient to use kqemu (or KVM) to handle the address space remapping.
The trick is to run the translator in the upper part or lower part of
the 32 bit ad
When you run "qemu -h", help() is called with optarg==NULL, which
causes a segfault on my system (Solaris-10U3_x86, 64-bit kernel,
but qemu compiled as 32-bit app, gcc-3.4.5 from blastwave.org).
It's a side-effect of the -r1.315 patch which fixed related segfaults.
The following patch fixes the "-
Hi,
2007/6/29, Paul Brook <[EMAIL PROTECTED]>:
I'd expect the overhead of SIGSEGV+mmap to be prohibitive. I don't have
numbers to back this up, but experience with MIPS system emulation shows that
TLB miss cost can have significant effect on overall performance.
I'd say this can't be worse tha
On 6/29/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
In fact, running in 64 bit is not necessary : It is simpler and more
efficient to use kqemu (or KVM) to handle the address space remapping.
The trick is to run the translator in the upper part or lower part of
the 32 bit address space and to
Hi,
thanks to Andrzej Zaborowski there's now a PXA270 based machine (or
more precisely 4 machines) in the development branch. Did anybody manage
to try it out? Is there a test image prepared for the PXA270
environment? I've tried arm-test-0.2.tar.gz but nothing happened.
Thanks for any
Thiemo Seufer wrote:
Jason Wessel wrote:
The attached patch adds loadvm and savevm support to the e100 driver.
One note about this patch is that the image is not portable across
big/little endian hosts. Since it already appeared that the save/load
images in general are not portable betwe
Hello,
I have qemu-0.9.0 (installed via deb package) on debian-amd64 unstable
on a turion64 hp notebook.
I have detected the following bugs when using the command
"qemu-system-x86_64 -hda /dev/hda":
1) I use grub-0.97 to boot my system. Qemu (meaning the above command)
always boots the same ima
Hi,
2007/6/26, Karl Magdsick <[EMAIL PROTECTED]>:
With proper support from the compiler, it's theoretically possible on
x86-64 systems to use 32-bit pointers in long mode (16 general purpose
64-bit registers). (There's an instruction prefix that will cause the
CPU to perform 32-bit pointer cal
Jason Wessel wrote:
> The attached patch adds loadvm and savevm support to the e100 driver.
>
> One note about this patch is that the image is not portable across
> big/little endian hosts. Since it already appeared that the save/load
> images in general are not portable between a big/little e
> One note about this patch is that the image is not portable across
> big/little endian hosts. Since it already appeared that the save/load
> images in general are not portable between a big/little endian hosts I
> just took the short cut of pushing the struct members that were not
> being saved
While using the gdb stub on the PPC target you cannot set registers if
the machine has the power save bit set in the msr without crashing
QEMU. The reason it crashes is because the cpu_loop_exit() function
will get called when the gdb stub is setting the registers.
There is certainly more tha
The attached patch adds loadvm and savevm support to the e100 driver.
One note about this patch is that the image is not portable across
big/little endian hosts. Since it already appeared that the save/load
images in general are not portable between a big/little endian hosts I
just took the
> I had an idea of mapping the full 32-bit target virtual address space
> to a 4GB area on 64-bit hosts. Then the loads and stores to normal RAM
> (except page tables, code_mem_write etc) could be made much faster,
> falling back to softmmu for other pages. The idea has come up before,
> for exampl
The check in qemu_can_send_packet() does not work correctly when using
multiple nics. I found the problem when using -boot n and having more
than one nic in use with the SLIRP networking. The
qemu_can_send_packet() is only called as a part of the SLIRP networking
check to see if there is a va
Right now the gdb stub support is mutually exclusive of the loadvm
command line support. In fact it might be nice to have the loadvm and
savevm commands exposed via the gdb stub so you can save an instance
which you can debug again later.
The attached patch makes it so you can execute a -load
Hi,
In fact, running in 64 bit is not necessary : It is simpler and more
efficient to use kqemu (or KVM) to handle the address space remapping.
The trick is to run the translator in the upper part or lower part of
the 32 bit address space and to protect it with segments.
Even in 64 bit mode,
Hi,
I had an idea of mapping the full 32-bit target virtual address space
to a 4GB area on 64-bit hosts. Then the loads and stores to normal RAM
(except page tables, code_mem_write etc) could be made much faster,
falling back to softmmu for other pages. The idea has come up before,
for example in
Andreas Färber wrote:
Am 28.06.2007 um 17:26 schrieb Blue Swirl:
I found the problem, it wasn't related to Debian's 2.6 kernel after
all, but pcnet just didn't work on a 32-bit host. I'm committing a
fix.
Big thanks for fixing this! Works now. :-)
And here as well. Well done, thanks.
And
27 matches
Mail list logo
