I appreciate the work that Jocelyn did to correct the types used
throughout linux-user/syscall.c. Along those same lines I am working on
several patches to eliminate some incorrect constructs that have crept
into syscall.c - some of which I have ignorantly propagated in previous
patches that I hav
On Wed, Oct 10, 2007 at 06:20:57PM -0500, Rob Landley wrote:
> On Saturday 06 October 2007 8:59:02 pm Ian Graeme Hilt wrote:
> > Two questions:
> >
> > 1. Why does qemu-system-m68k require a kernel image?
>
> I'd actually be pretty happy if I could figure out which kernel image I could
> build th
On Saturday 06 October 2007 8:59:02 pm Ian Graeme Hilt wrote:
> Two questions:
>
> 1. Why does qemu-system-m68k require a kernel image?
I'd actually be pretty happy if I could figure out which kernel image I could
build that the sucker would boot.
"qemu-system-m68k -M ?" lists two boards: the mc
On Wed, 2007-10-10 at 22:02 +0300, Blue Swirl wrote:
> On 10/10/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> > Thiemo Seufer wrote:
> > > Fabrice Bellard wrote:
> > >> J. Mayer wrote:
> > >>> Following the patches done for elfload32, it appeared to me that there
> > >>> were still problems that
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 07/10/10 19:11:54
Modified files:
target-sparc : op.c translate.c
Log message:
Fix taddcctv and tsubcctv (David Matthews)
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cv
On 10/10/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> Thiemo Seufer wrote:
> > Fabrice Bellard wrote:
> >> J. Mayer wrote:
> >>> Following the patches done for elfload32, it appeared to me that there
> >>> were still problems that would prevent 32 bits executables to run on 64
> >>> bits target
On Wed, 2007-10-10 at 19:01 +0300, Blue Swirl wrote:
> On 10/10/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > Following the patches done for elfload32, it appeared to me that there
> > were still problems that would prevent 32 bits executables to run on 64
> > bits target in linux user mode emulation
Thiemo Seufer wrote:
Fabrice Bellard wrote:
J. Mayer wrote:
Following the patches done for elfload32, it appeared to me that there
were still problems that would prevent 32 bits executables to run on 64
bits target in linux user mode emulation.
[...]
Are you sure it is a good idea to try to add
Fabrice Bellard wrote:
> J. Mayer wrote:
>> Following the patches done for elfload32, it appeared to me that there
>> were still problems that would prevent 32 bits executables to run on 64
>> bits target in linux user mode emulation.
> > [...]
>
> Are you sure it is a good idea to try to add 32 bi
This patch fixes a couple of bugs in taddcctv and tsubcctv on the Sparc.
It saves the state so that if the instructions trap the correct
address is delivered to the kernel and it fixes the detection of
overflow in taddcctv. This was patched against CVS version of 20070816
but the fixes don't
On 10/10/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> J. Mayer wrote:
> > Following the patches done for elfload32, it appeared to me that there
> > were still problems that would prevent 32 bits executables to run on 64
> > bits target in linux user mode emulation.
> > [...]
>
> Are you sure
On 10/10/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> Following the patches done for elfload32, it appeared to me that there
> were still problems that would prevent 32 bits executables to run on 64
> bits target in linux user mode emulation.
> First of all, the personality was never set to PER_LINUX3
hi everyone!
I have a question concerning how i386 execution is continued after a page
fault has occured...
What I have understood so far:
In the executing TB the TLB is checked and if the address is not found
__ld (e.g. __ldl_user)
is called. this calls
lb_fill
(if it rea
Avi Kivity a écrit :
> Aurelien Jarno wrote:
>> Avi Kivity a écrit :
>>
>>> Aurelien Jarno wrote:
>>>
>> I also confirm that using -no-acpi fixes the problem. However, I have
>> seen strange data corruption, even on Intel.
>>
>> Basically, booting a recently installed FreeBS
Some x86_64 SSE2 instructions that convert floats to ints appear
to ignore the rounding mode (in mxcsr), and so produce wrong results
if mxcsr is set to anything other than default rounding. For example
cvtsd2si et al.
I'm looking at softfloat-native.c and softfloat.c and wondering how
to fix it
I was curious if anyone thinks that it may be possible to get a
KVM-patched QEMU to use a real video card? For example, let's say I had
a second video card. Is QEMU a codebase which would support hacking in
the ability to utilize this second video card? And in the situation of a
laptop, would i
J. Mayer wrote:
Following the patches done for elfload32, it appeared to me that there
were still problems that would prevent 32 bits executables to run on 64
bits target in linux user mode emulation.
> [...]
Are you sure it is a good idea to try to add 32 bit executable support
to a 64 bit ta
Following the patches done for elfload32, it appeared to me that there
were still problems that would prevent 32 bits executables to run on 64
bits target in linux user mode emulation.
First of all, the personality was never set to PER_LINUX32
The second problem was that pointers used to set the va
18 matches
Mail list logo
