On 27 February 2014 13:20, Michael Matz wrote:
> On Wed, 26 Feb 2014, Dann Frazier wrote:
>> I've narrowed down the changes that seem to prevent both types of
>> segfaults to the following changes that introduce a wrapper around
>> sigprocmask:
>>
>> https://github.com/susematz/qemu/commit/f1542ae
On 2014-02-25 15:54:37 +, Alex Bennée wrote:
>
> >> Feedback I'm interested in
> >> ==
> >>
> >> * Any instruction failure (please include the log line with the
> >> unsupported message)
> >
> > Neon support is not complete enough to run the hand written neon
> > assem
On 2014-03-06 11:40:47 +, Alex Bennée wrote:
>
> Janne Grunau writes:
>
> > On 2014-02-25 15:54:37 +, Alex Bennée wrote:
> >>
>
> >> Have you got the log file "unsupported" line? I seem to recall you did
> >> ping me but maybe it was just on IRC? I just want to make sure I
> >> do the r
Hi,
On 2014-02-17 13:40:00 +, Alex Bennée wrote:
>
> After a solid few months of work the QEMU master branch [1] has now reached
> instruction feature parity with the suse-1.6 [6] tree that a lot of people
> have been using to build various aarch64 binaries. In addition to the
> SUSE work we
Hi,
On Mon, 10 Mar 2014, Alex Bennée wrote:
> > Not sure there's much point looking very deeply into this. Java
> > programs are threaded, threaded programs don't work under QEMU =>
> > don't try to run Java under QEMU :-)
>
> Having said that I'm sure there was another SIGILL related crash on
On 10 March 2014 11:28, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> On 9 March 2014 23:37, Dann Frazier wrote:
>>> Also - I've found an issue with running OpenJDK in the latest upstream git:
>>>
>>> root@server-75e0210e-4f99-4c86-9277-3201ab7b6afd:/root# java
>>> #
>>> [thread 274902467056
Peter Maydell writes:
> On 9 March 2014 23:37, Dann Frazier wrote:
>> Also - I've found an issue with running OpenJDK in the latest upstream git:
>>
>> root@server-75e0210e-4f99-4c86-9277-3201ab7b6afd:/root# java
>> #
>> [thread 274902467056 also had an error]# A fatal error has been
>> detecte
On 9 March 2014 23:37, Dann Frazier wrote:
> Also - I've found an issue with running OpenJDK in the latest upstream git:
>
> root@server-75e0210e-4f99-4c86-9277-3201ab7b6afd:/root# java
> #
> [thread 274902467056 also had an error]# A fatal error has been
> detected by the Java Runtime Environment
On Tue, Feb 25, 2014 at 1:39 AM, Alex Bennée wrote:
>
> Dann Frazier writes:
>
>> On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée wrote:
>>> Hi,
>>
>> Thanks to all involved for your work here!
>>
>>> After a solid few months of work the QEMU master branch [1] has now reached
>>> instruction featur
Janne Grunau writes:
> On 2014-02-25 15:54:37 +, Alex Bennée wrote:
>>
>> Have you got the log file "unsupported" line? I seem to recall you did
>> ping me but maybe it was just on IRC? I just want to make sure I
>> do the right ones. I'm working on this now.
>
> We spoke on irc about it. a
On 28 February 2014 17:08, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> On 28 February 2014 14:27, Alexander Graf wrote:
>>> Could we check the instruction at the sognaling pc and check
>>> if it's a known syscall instruction? No need to replace glibc
>>> wrappers then.
>>
>> No, because th
Peter Maydell writes:
> On 28 February 2014 14:27, Alexander Graf wrote:
>> Could we check the instruction at the sognaling pc and check
>> if it's a known syscall instruction? No need to replace glibc
>> wrappers then.
>
> No, because the behaviour we want for "started handling
> syscall in qe
On 28 February 2014 14:27, Alexander Graf wrote:
> Could we check the instruction at the sognaling pc and check
> if it's a known syscall instruction? No need to replace glibc
> wrappers then.
No, because the behaviour we want for "started handling
syscall in qemu" through to "PC anything up to b
On 28 February 2014 14:12, Alex Bennée wrote:
> Is this "simply" a case of having a precise state in/around syscalls?
No.
> AIUI we already have such a mechanism for dealing with faults in
> translated code so this is all aimed at when an asynchronous signal
> arrives somewhere in QEMU's own cod
> Am 28.02.2014 um 22:21 schrieb Peter Maydell :
>
>> On 28 February 2014 14:12, Alex Bennée wrote:
>> Is this "simply" a case of having a precise state in/around syscalls?
>
> No.
>
>> AIUI we already have such a mechanism for dealing with faults in
>> translated code so this is all aimed at
Michael Matz writes:
> Hi,
>
> On Tue, 25 Feb 2014, Peter Maydell wrote:
>
>> On 25 February 2014 13:33, Michael Matz wrote
>> > The biggest road-block is that signal vs syscall handling is
>> > fundamentally broken in linux-user and it's unfixable without
>> > assembler implementations of the
[Adding Alex Barcelo to the CC]
On Thu, Feb 27, 2014 at 6:20 AM, Michael Matz wrote:
> Hi,
>
> On Wed, 26 Feb 2014, Dann Frazier wrote:
>
>> I've narrowed down the changes that seem to prevent both types of
>> segfaults to the following changes that introduce a wrapper around
>> sigprocmask:
>>
>
Hi,
On Wed, 26 Feb 2014, Dann Frazier wrote:
> I've narrowed down the changes that seem to prevent both types of
> segfaults to the following changes that introduce a wrapper around
> sigprocmask:
>
> https://github.com/susematz/qemu/commit/f1542ae9fe10d5a241fc2624ecaef5f0948e3472
> https://gith
On Tue, Feb 25, 2014 at 1:39 AM, Alex Bennée wrote:
>
> Dann Frazier writes:
>
>> On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée wrote:
>>> Hi,
>>
>> Thanks to all involved for your work here!
>>
>>> After a solid few months of work the QEMU master branch [1] has now reached
>>> instruction featur
Janne Grunau writes:
> Hi,
>
> On 2014-02-17 13:40:00 +, Alex Bennée wrote:
>>
>
>> In my tree the remaining insns that the GCC aarch64 tests need to
>> implement are:
>> FRECPE
>> FRECPX
>> CLS (2 misc variant)
>> CLZ (2 misc variant)
>> FSQRT
My GitHub tree now has f
Hi,
On Tue, 25 Feb 2014, Peter Maydell wrote:
> On 25 February 2014 13:33, Michael Matz wrote
> > The biggest road-block is that signal vs syscall handling is
> > fundamentally broken in linux-user and it's unfixable without
> > assembler implementations of the syscall caller.
>
> I'm not entir
On 25 February 2014 13:33, Michael Matz wrote
> The biggest road-block is that signal vs syscall handling is
> fundamentally broken in linux-user and it's unfixable without
> assembler implementations of the syscall caller.
I'm not entirely sure it's possible to fix even with
hand-rolled assembly
Hi,
On Tue, 25 Feb 2014, Andreas Färber wrote:
> >> There are some pretty large differences between these trees with
> >> respect to signal syscalls - is that the likely culprit?
> >
> > Quite likely. We explicitly concentrated on the arch64 specific
> > instruction emulation leaving more gene
Am 25.02.2014 09:39, schrieb Alex Bennée:
>
> Dann Frazier writes:
>
>> On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée wrote:
>>> Hi,
>>
>> Thanks to all involved for your work here!
>>
>>> After a solid few months of work the QEMU master branch [1] has now reached
>>> instruction feature parity
Dann Frazier writes:
> On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée wrote:
>> Hi,
>
> Thanks to all involved for your work here!
>
>> After a solid few months of work the QEMU master branch [1] has now reached
>> instruction feature parity with the suse-1.6 [6] tree that a lot of people
>> have
On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée wrote:
> Hi,
Thanks to all involved for your work here!
> After a solid few months of work the QEMU master branch [1] has now reached
> instruction feature parity with the suse-1.6 [6] tree that a lot of people
> have been using to build various aarch
26 matches
Mail list logo
