Thank you, Mark.
Acked-by: Artyom Tarasenko
On Wed, Jun 8, 2016 at 12:09 AM, Mark Cave-Ayland
wrote:
> On 07/06/16 23:04, Mark Cave-Ayland wrote:
>
>> Artyom has been working on QEMU's SPARC emulation for several years,
>> providing
>> initial support for Solari
--
> target-sparc/ldst_helper.c | 696 +++-
> target-sparc/translate.c | 1273
>
> 6 files changed, 1607 insertions(+), 1099 deletions(-)
> create mode 100644 target-sparc/asi.h
>
> --
> 2.5.5
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
around? I think it would be nice to implement
a persistent RAM as a feature, specified by a command line switch.
Regards,
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
nals-how-guest-physical-ram.html
Regards,
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Thu, Apr 14, 2016 at 4:20 PM, Mark Cave-Ayland
wrote:
> On 14/04/16 15:04, Artyom Tarasenko wrote:
>
>> Can you please show the output of your checkpatch.pl report? I get:
>>
>> $ scripts/checkpatch.pl
>> 0001-target-sparc-fix-Nucleus-quad-LDD-128-bit-access-f
On Thu, Apr 14, 2016 at 3:43 PM, Mark Cave-Ayland
wrote:
> On 14/04/16 10:29, Artyom Tarasenko wrote:
>
>> Accoding the chapter 7.6 Trap Processing of the SPARC Architecture Manual v9,
>> the Trap Based Address Register is not modified as a trap is taken.
>>
>> T
On Thu, Apr 14, 2016 at 3:42 PM, Mark Cave-Ayland
wrote:
> On 14/04/16 10:29, Artyom Tarasenko wrote:
>
>> Fix register offset calculation when regwptr is used.
>>
>> Signed-off-by: Artyom Tarasenko
>> ---
>> target-sparc/ldst_helper.c | 12 ++--
&g
Accoding the chapter 7.6 Trap Processing of the SPARC Architecture Manual v9,
the Trap Based Address Register is not modified as a trap is taken.
This fix allows booting FreeBSD-10.3-RELEASE-sparc64.
Signed-off-by: Artyom Tarasenko
---
target-sparc/int64_helper.c | 5 ++---
1 file changed, 2
Fix register offset calculation when regwptr is used.
Signed-off-by: Artyom Tarasenko
---
target-sparc/ldst_helper.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/target-sparc/ldst_helper.c b/target-sparc/ldst_helper.c
index 2b0221c..a383074 100644
--- a
ding a condensed test image to
> consistently
> reproduce the problem on demand, and Martin Husemann for allowing me access to
> real hardware for comparison.
>
> Signed-off-by: Mark Cave-Ayland
Reviewed-By: Artyom Tarasenko
> ---
> target-sparc/translate.c |2 +-
> 1 file c
hronization/locking scheme should
> + * be implemented.
> + */
> if (!tb->jmp_list_next[n]) {
> /* patch the native jump address */
> tb_set_jmp_target(tb, n, (uintptr_t)tb_next->tc_ptr);
> --
> 2.7.3
>
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
; [ 16.051094] [005cfc7c] __clear_user+0x18/0xb8
> [ 16.051579] [00542128] load_elf_binary+0x760/0x1194
> [ 16.052099] [00504500] search_binary_handler+0x120/0x354
> [ 16.052652] [0053f38c] load_script+0x23c/0x250
> [ 16.053134] [005
slog service starting.
> savecore: no dump device configured
> Running in command line mode
>
> And nothing happens after that. Anyone encountered this issue?
Does the boot log look like the "good" or the "bad" example from the link below?
http://tyom.blogspot.de/2010/05/sx-framebuffer-emulation.html
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
regression in the patch 13/25 (which btw seems
not to have make it to the list).
A quick attempt to debug it didn't succeed: from a log it looks like
the corruption happens after a 'nop' instruction, and setting a
breakpoint changes the behavior (optimizer bug?)
I'll send you a
On Fri, Jan 15, 2016 at 7:03 PM, Richard Henderson wrote:
> On 01/15/2016 05:17 AM, Artyom Tarasenko wrote:
>> Hi Richard,
>>
>> please ignore my 2 previous mails: I've misread the commit message.
>> The actual problem and a possible solution below.
>>
>&
t; before
> - another fault) */
> -} else {
> -env->immu.sfsr = 0;
> +/* overflow (not read before another fault) */
> +sfsr |= SFSR_OW_BIT;
> }
> if (env->pstate & PS_PRIV) {
> -env->immu.sfsr |= SFSR_PR_BIT;
> -}
> -if (env->tl > 0) {
> -env->immu.sfsr |= SFSR_CT_NUCLEUS;
> +sfsr |= SFSR_PR_BIT;
> }
>
> /* FIXME: ASI field in SFSR must be set */
> -env->immu.sfsr |= SFSR_FT_PRIV_BIT | SFSR_VALID_BIT;
> +env->immu.sfsr |= sfsr | SFSR_FT_PRIV_BIT | SFSR_VALID_BIT;
> cs->exception_index = TT_TFAULT;
>
> env->immu.tag_access = (address & ~0x1fffULL) | context;
> --
> 2.5.0
>
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
I have a weak suggestion we call them UA2005 defines,
because all of them are already described in UA2005 and
the commit message can make it easier to distinguish what ASIs have to
be implemented for UST1+ and what on UST4+ only).
Otherwise,
Reviewed-By: Artyom Tarasenko
On Thu, Dec 17, 2015
On Mon, Jan 11, 2016 at 12:15 PM, Artyom Tarasenko wrote:
> Hi Richard,
>
> first of all, this is a very nice series.
> I really enjoy reading it, thank you very much.
> It makes the code is more readable and likely to be more performant.
> A nitpick below.
>
> On Thu,
if (env->immu.sfsr & SFSR_VALID_BIT) {
> -env->immu.sfsr = SFSR_OW_BIT; /* overflow (not read
> before
> - another fault) */
> -} else {
> -env->immu.sfsr = 0;
Looks good.
Reviewed-By: Artyom Tarasenko
On Fri, Nov 13, 2015 at 6:54 PM, Mark Cave-Ayland
wrote:
> Whilst trying to boot FreeBSD SPARC64, it became apparent that the existing
> timer code doesn't behave correctly with respect to the NPT and INT_DIS
> bits. This patchset
On Thu, Sep 10, 2015 at 1:02 PM, Dennis Luehring wrote:
> Am 10.09.2015 um 12:37 schrieb Dennis Luehring:
>>
>> Am 10.09.2015 um 11:54 schrieb Artyom Tarasenko:
>> > On Thu, Sep 10, 2015 at 11:32 AM, Dennis Luehring
>> > wrote:
>> >> >
On Thu, Sep 10, 2015 at 11:32 AM, Dennis Luehring wrote:
> Am 10.09.2015 um 09:00 schrieb Artyom Tarasenko:
>>>
>>> >strangly your branch doesn't changed anything for pure SPARC64 in my
>>> > tests -
>>> >i've always completely removed the
78.1 0.578641 0.575289 0.586838
> Scale:178.7 0.903208 0.895518 0.907769
> Add: 210.8 1.144200 1.138318 1.156063
> Triad:165.2 1.459674 1.453116 1.479194
>
> g++ src/pugixml.cpp -g -Wall -Wextra -Werror -pedantic -std=c++0x -c -MMD
> -MP
>
> compile times
> 156.85 real 148.98 user 7.17 sys
> 157.05 real 149.99 user 6.78 sys
> 157.48 real 150.25 user 6.92 sys
> 156.50 real 149.06 user 6.60 sys
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Wed, Sep 9, 2015 at 6:18 PM, Paolo Bonzini wrote:
>
>
> On 09/09/2015 17:05, Artyom Tarasenko wrote:
>> Hi Richard,
>>
>> On Tue, Sep 8, 2015 at 9:00 PM, Richard Henderson wrote:
>>> On 09/08/2015 11:56 AM, Peter Maydell wrote:
>>>> My sparc
. Something more than the trivial sparc-test image on
> the wiki. Something with a sparc64 userland would be best.
In case you still need it I can give you my working debian-sid/sparc64
image, but it's huge (~4GB), nothing for a mail.
Artyom
--
Regards,
Artyom Tarasenko
SPARC
ibed here [1]) shows ~3x speed up
factor. Not bad!
So, for the sparc64 part,
Tested-By: Artyom Tarasenko
1. https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02220.html
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Wed, Aug 26, 2015 at 9:47 PM, Richard Henderson wrote:
> On 08/26/2015 09:17 AM, Artyom Tarasenko wrote:
>>
>> After some debugging I think it's caused by memory faults. On every
>> MMU miss / access fault
>> TB is re-translated multiple times till the faulting
binaries would not work,
but it should not be a problem, since the userspace of the released
Debian/sparc is pure sparc32plus and the userspace of the unreleased
Debian/sparc64 is pure sparc64.
Artyom
1. https://wiki.debian.org/QemuUserEmulation
2. http://tyom.blogspot.de/2011/07/user-mode-em
Hi Richard,
On Sun, Aug 23, 2015 at 2:41 AM, Richard Henderson wrote:
> On Aug 22, 2015 9:45 AM, Artyom Tarasenko wrote:
>> For my test case tcg-indirect brings more performance gain than for Dennis:
>>
>> git master: 18m31s
>> tcg-indirect: 16m50s
>> #und
On Tue, Aug 25, 2015 at 4:25 PM, Richard Henderson wrote:
> On 08/24/2015 11:44 PM, Artyom Tarasenko wrote:
>>
>> This is very surprising: the patch should have no effect on a sun4u
>> machine.
>
>
> Er, no, it should. The primary vector by which I expect imp
; FunctionBest Rate MB/s Avg time Min time Max time
> Copy: 276.2 0.585113 0.579193 0.595607
> Scale:181.3 0.895991 0.882744 0.917396
> Add: 215.9 1.126226 1.111750 1.174236
> Triad:167.0 1.469888 1.436790 1.523211
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
static inline bool tb_fpu_enabled(int tb_flags)
> diff --git a/target-sparc/translate.c b/target-sparc/translate.c
> index 48fc2ab..8254a30 100644
> --- a/target-sparc/translate.c
> +++ b/target-sparc/translate.c
> @@ -5234,7 +5234,7 @@ static inline void
> gen_intermediate_code_i
s under qemu-system-sparc64 the comparable amount
of time is spent on executing and generating the code [1].
Does this lock imply the translation performance won't gain anything
when emulating a single core machine on a multi-core one?
Artyom
1. https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02194.html
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Sat, Aug 22, 2015 at 7:47 PM, Dennis Luehring wrote:
> Am 22.08.2015 um 18:45 schrieb Artyom Tarasenko:
>>
>> git master: 18m31s
>> tcg-indirect: 16m50s
>> #undef USE_TCG_OPTIMIZATIONS: 14m18s
>
>
> my results are not totaly different to yours - ~
On Thu, Aug 20, 2015 at 7:22 AM, Dennis Luehring wrote:
> Am 19.08.2015 um 16:41 schrieb Artyom Tarasenko:
>>
>> And if I completely disable optimizer (// #define
>> USE_TCG_OPTIMIZATIONS in tcg.c), it's still quite faster:
>>
>> real14m17.668s
>
Hi Richard,
On Tue, Aug 18, 2015 at 7:55 PM, Richard Henderson wrote:
> On 08/18/2015 02:24 AM, Artyom Tarasenko wrote:
>> The unoptimized case is a sequence of multiple cmp and branch
>> operations (likely created by a "case" statement in the original
>> source co
On Mon, Aug 3, 2015 at 11:17 AM, Aurelien Jarno wrote:
> On 2015-08-03 10:31, Artyom Tarasenko wrote:
>> Hi Aurelien,
>>
>> On Fri, Jul 31, 2015 at 5:43 PM, Aurelien Jarno wrote:
>>
>> >> > It uses a lot of integer functions
>> >> > based
Hi Mark,
On Mon, Aug 17, 2015 at 8:22 PM, Mark Cave-Ayland
wrote:
> On 14/08/15 13:15, Artyom Tarasenko wrote:
>
> Hi Artyom,
>
>> Hi Mark,
>>
>> On Fri, Aug 14, 2015 at 12:37 AM, Mark Cave-Ayland
>> wrote:
>>> On 10/08/15 13:34, Peter Maydell wrote
On Mon, Aug 17, 2015 at 5:40 PM, Richard Henderson wrote:
> On 08/17/2015 07:19 AM, Artyom Tarasenko wrote:
>> Well, on the other hand, every access goes via helper_check_align.
>> There is a comment /* XXX remove alignment check */.
>> I wonder how this can be done in
On Mon, Aug 17, 2015 at 5:44 PM, Richard Henderson wrote:
> On 08/17/2015 04:35 AM, Artyom Tarasenko wrote:
>> Hi Richard,
>>
>> this patch seems to break a build when USE_LIVENESS_ANALYSIS is undefined.
>
> I suppose that's possible. If so, it must be a trivi
ng a brcond instruction would require that
all TCG temps would have to be changed to locals, which in turn would
produce a performance impact. Are there other ways of doing it?
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
Hi Richard,
this patch seems to break a build when USE_LIVENESS_ANALYSIS is undefined.
Regards,
Artyom
On Fri, Feb 13, 2015 at 6:43 AM, Richard Henderson wrote:
> The previous setup required ops and args to be completely sequential,
> and was error prone when it came to both iteration and optim
back to the newer qcow2 again...
I think you and Peter speak about different snapshots. The filesystem
snapshots are not affected with this series, so no need to convert
qcow2 back and force.
What would be broken is the live system snapshot - it won't be
possible to live migrate from one QEMU version to another one without
rebooting the guest.
But I guess a reboot for a QEMU upgrade is not too expensive for our
current users.
ATB,
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
struction,
b) all flags for one instruction,
c) one flag for all instructions,
or d) all flags for all instructions (gradually moving to setcond is
not possible) ?
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
the QEMU problem, the issue is that the 64-bit code
> is using the udivx instruction to compute the modulo, while the 32-bit
> code calls the __umoddi3 GCC helper.
Actually this looks like a bug/missing feature in gcc. Why doesn't it use udivx
instruction in "SPARC32PLUS, V8+ Required" code?
> It uses a lot of integer functions
> based on CPU flags, so most of the time is spent computing them in
> helper_compute_psr.
I wonder if this can be optimized. I guess most RISC CPUs would have a
similar problem. Unlike x86, the compilers usually optimize
instructions on flag usage. If there is an instruction modifying flags
in a code, the flags will be used for sure, so it probably makes a
little sense to pospone the flag computation?
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
116s
> sparc64 guest (sparc64 kernel) 4.4908s
Wow. That's quite a difference. What have you used as a sparc64 guest?
Are there any ready-to-use distributions, or have you built it from scratch?
> So it looks like the 32-bit code is not QEMU friendly. I haven't looked
> at it yet, b
d help. If it is able to run
translation an execution of code in different threads, it would nearly
double the performance.
Adding mttcg to CC, with a hope to hear from the authors whether their
thread model brings something when emulating a single CPU, or is it
only oriented to SMP machines.
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
ne.
1. http://people.csail.mit.edu/fredette/tme/index.html
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Wed, Jul 29, 2015 at 8:20 AM, Dennis Luehring wrote:
> Am 28.07.2015 um 11:54 schrieb Artyom Tarasenko:
>>>
>>> >anything i can do to speedup the emulation?
>>
>> Maybe try the fresh tcg optimizer improvements from Aurelien:
>> https://lists.gnu.or
anything i can do to speedup the emulation?
Maybe try the fresh tcg optimizer improvements from Aurelien:
https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg05133.html
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
Use VEC_OR macro for operations on VECTYPE operands
Signed-off-by: Artyom Tarasenko
---
util/cutils.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/util/cutils.c b/util/cutils.c
index 144b25c..5d1c9eb 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -207,13
changes from the initial version: create a VEC_OR macro as suggested by Paolo
Artyom Tarasenko (2):
qemu-common: add VEC_OR macro
cutils: allow compilation with icc
include/qemu-common.h | 3 +++
util/cutils.c | 14 +++---
2 files changed, 10 insertions(+), 7 deletions
Intel C Compiler version 15.0.3.187 Build 20150407 doesn't support
'|' function for non floating-point simd operands.
Define VEC_OR macro which uses _mm_or_si128 supported
both in icc and gcc on x86 platform.
Signed-off-by: Artyom Tarasenko
---
include/qemu-common.h | 3 +++
1
Intel C Compiler version 15.0.3.187 Build 20150407 doesn't support
'|' function for non floating-point simd operands.
Use instead _mm_or_si128 which is supported both in icc and gcc.
Signed-off-by: Artyom Tarasenko
---
util/cutils.c | 14 +++---
1 file changed, 7 i
On Mon, Jun 15, 2015 at 5:50 PM, Richard Henderson wrote:
> On 06/11/2015 01:59 AM, Artyom Tarasenko wrote:
>>
>> This is a very promising approach. Would it also work on a large
>> numbers of MMU modes?
>> Particulary I wonder if it would work for SPARC, where 32-b
et.h| 1 +
> tcg/sparc/tcg-target.h | 1 +
> tcg/tci/tcg-target.h | 1 +
> 14 files changed, 156 insertions(+), 22 deletions(-)
>
> --
> 2.3.5
>
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
| 11 ++
> 8 files changed, 948 insertions(+)
> create mode 100644 docs/ibm_40p.cfg
> create mode 100644 hw/ppc/prep_systemio.c
> create mode 100644 hw/ppc/rs6000_debug.c
> create mode 100644 hw/ppc/rs6000_mc.c
>
> --
> 2.1.4
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
apply it, you'll be then able to create a sysbus-m48t02 device, and
> then to add it to ebus memory region.
Why m48t02? As discussed before, it shall be a m48t59 device:
http://lists.gnu.org/archive/html/qemu-devel/2013-04/msg05559.html
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Mon, Jan 19, 2015 at 9:03 PM, Andreas Färber wrote:
> Am 19.01.2015 um 16:22 schrieb Artyom Tarasenko:
>> On Mon, Jan 19, 2015 at 4:01 PM, Andreas Färber wrote:
>>> Am 19.01.2015 um 13:57 schrieb Artyom Tarasenko:
>>>> On Mon, Jan 19, 2015 at 1:45 PM, Paolo Bonzi
On Mon, Jan 19, 2015 at 4:31 PM, Paolo Bonzini wrote:
>
>
> On 19/01/2015 16:22, Artyom Tarasenko wrote:
>>>> >>
>>>> >> On physical machines it's EBus, which is pretty much like 8-bit ISA.
>>>> >> So, I think modelling it as ISA
On Mon, Jan 19, 2015 at 4:01 PM, Andreas Färber wrote:
> Am 19.01.2015 um 13:57 schrieb Artyom Tarasenko:
>> On Mon, Jan 19, 2015 at 1:45 PM, Paolo Bonzini wrote:
>>> On 19/01/2015 12:35, Mark Cave-Ayland wrote:
>>>> Similar to m48t59_init(), add a mem_base val
On Mon, Jan 19, 2015 at 1:59 PM, Paolo Bonzini wrote:
>
>
> On 19/01/2015 13:57, Artyom Tarasenko wrote:
>>> > Is it really ISA if it's MMIO? In other words, why can't this be a
>>> > sysbus device?
>> On physical machines it's EBus, which i
ible to have a sysbus device
somewhere in a middle of PCI space? Do sysbus devices have higher
priority if the address spaces overlap? Or do you mean that the PCI
controller needs to be modified to have a hole for a sysbus device?
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
the same as an ISA bus.
>
> Signed-off-by: Mark Cave-Ayland
Reviewed-by: Artyom Tarasenko
> Mark Cave-Ayland (2):
> m48t59: introduce new year_offset qdev property
> m48t59: add mem_base value to m48t59_init_isa()
>
> hw/ppc/ppc405_boards.c|2 +-
> hw/ppc/pr
,
> +DEFINE_PROP_UINT32("year_offset", M48t59SysBusState, state.year_offset,
> 0),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> diff --git a/include/hw/timer/m48t59.h b/include/hw/timer/m48t59.h
> index 8217522..08252b6 100644
> --- a/include/hw/timer/m48t59.h
> +++ b/include/hw/timer/m48t59.h
> @@ -30,8 +30,9 @@ void m48t59_write (void *private, uint32_t addr, uint32_t
> val);
> uint32_t m48t59_read (void *private, uint32_t addr);
> void m48t59_toggle_lock (void *private, int lock);
> M48t59State *m48t59_init_isa(ISABus *bus, uint32_t io_base, uint16_t size,
> - int type);
> + uint32_t year_offset, int type);
> M48t59State *m48t59_init(qemu_irq IRQ, hwaddr mem_base,
> - uint32_t io_base, uint16_t size, int type);
> + uint32_t io_base, uint16_t size,
> + uint32_t year_offset, int type);
>
> #endif /* !NVRAM_H */
> --
> 1.7.10.4
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Thu, Nov 27, 2014 at 6:45 PM, Paolo Bonzini wrote:
>
>
> On 27/11/2014 10:53, Artyom Tarasenko wrote:
>>> >
>>> > Deterministic replay has the following features:
>>> > * Deterministically replays whole system execution and all contents of
>
gested by Paolo Bonzini)
> * Extracted saving of exception_index to separate patch (as suggested by
> Paolo Bonzini)
>
> v2 changes:
> * Patches are split to be reviewable and bisectable (as suggested by Kirill
> Batuzov)
> * Added QMP versions of replay commands (as suggested by Eric Blake)
> * Removed some optional features of replay to make patches cleaner
> * Minor changes and code cleanup were made
>
>
>
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
On Thu, Nov 6, 2014 at 11:05 PM, Damien Hilloulin
wrote:
> Le 06/11/2014 19:23, Artyom Tarasenko a écrit :
>
>> On Thu, Nov 6, 2014 at 6:36 PM, Damien Hilloulin
>> wrote:
>>>
>>> Le 06/11/2014 16:27, Artyom Tarasenko a écrit :
>>>>
>>>
On Thu, Nov 6, 2014 at 6:36 PM, Damien Hilloulin
wrote:
> Le 06/11/2014 16:27, Artyom Tarasenko a écrit :
>>
>> Hello Damien,
>>
>> On Thu, Nov 6, 2014 at 8:38 AM, Damien Hilloulin
>> wrote:
>>>
>>> Hello everyone,
>>>
>>> I
. There was an attempt to do utilize
multiple threads for an ARM target:
http://sourceforge.net/p/coremu/home/Home
It would be interesting to hear what the TCG experts would say. Adding
Richard to CC.
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
exist?
Feedback is appreciated. In particular it would be nice to know if
there are guests which can boot under OHW, but not under OFW.
Artyom
--
Regards,
Artyom Tarasenko
SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu
rn address_mask(env, addr);
> @@ -296,6 +299,7 @@ static inline target_ulong asi_address_mask(CPUSPARCState
> *env,
> return addr;
> }
> }
> +#endif
>
> void helper_check_align(CPUSPARCState *env, target_ulong addr, uint32_t
> align)
> {
> --
> 1.9.1
>
>
--
Regards,
Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu
D_ENABLE;
> +
[nit-picking]
Shouldn't it be other way around: set the register to POR state (0)
here and set in OpenBIOS the desired values?
Currently OpenBIOS is the only firmware, so it doesn't matter, but who knows...
[/nit-picking]
Artyom
> if (s->nr_res
On Mon, Aug 25, 2014 at 7:58 PM, Mark Cave-Ayland
wrote:
> Both OpenBSD and FreeBSD SPARC64 attempt to read the interrupt map from the
> hardware and will fail if the correct ino isn't present.
>
> Signed-off-by: Mark Cave-Ayland
Reviewed-by: Artyom Tarasenko
> ---
> h
Implement Short Floating-Point Store Instructions as described
in the chapter 13.5.2 of UltraSPARC-IIi User's Manual.
Particularly this instructions are used by NetBSD 4.0.1+ /sparc64
Signed-off-by: Artyom Tarasenko
Tested-by: Mark Cave-Ayland
---
With this patch applied on top of c
On Tuesday, August 12, 2014, Richard Henderson wrote:
> On 08/08/2014 10:48 AM, Artyom Tarasenko wrote:
>> Implement Short Floating-Point Store Instructions as described
>> in the chapter 13.5.2 of UltraSPARC-IIi User's Manual.
>>
>> Particularly this instr
Implement Short Floating-Point Store Instructions as described
in the chapter 13.5.2 of UltraSPARC-IIi User's Manual.
Particularly this instructions are used by NetBSD 4.0.1+ /sparc64
Signed-off-by: Artyom Tarasenko
---
With this patch applied on top of cmd646 patches it's possible
00
> %f40:
> %f48:
> %f56:
> pstate: 0015
00
> %f48:
> %f56:
> pstate: 0015 ccr: 00 (icc: xcc: ) asi: 80 tl: 5 pil: e
>
On Mon, Mar 17, 2014 at 11:00 PM, Hervé Poussineau wrote:
> Signed-off-by: Hervé Poussineau
Reviewed-by: Artyom Tarasenko
> ---
> hw/pci-host/prep.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/pci-host/prep.c b/hw/pci-host/prep
binaries shared somewhere?
BTW is there any Linux distribution newer than Debian Woody available for PReP?
Artyom
>> On Mon, Feb 10, 2014 at 11:46 PM, Artyom Tarasenko
>> wrote:
>>> On Tue, Nov 5, 2013 at 12:09 AM, Hervé Poussineau
>>> wrote:
>>>> Sign
Hi Andreas, Hervé,
this patch seems still be missing in master. Is it causing any problems?
Artyom
On Mon, Feb 10, 2014 at 11:46 PM, Artyom Tarasenko wrote:
> On Tue, Nov 5, 2013 at 12:09 AM, Hervé Poussineau
> wrote:
>> Signed-off-by: Hervé Poussineau
>
> Without this pa
c/qemu/git/qemu/.git/rebase-apply/patch:49: trailing
> whitespace.
>
> All my SPARC32 and SPARC64 images run with no regressions, and there is a
> perceivable slight increase in performance here.
> Tested-by: Mark Cave-Ayland
Hi Mark,
I think a better test case would be looking for
onf-data", 4);
> memory_region_add_subregion(&s->pci_io, 0xcfc, &h->data_mem);
>
> memory_region_init_io(&h->mmcfg, OBJECT(s), &PPC_PCIIO_ops, s, "pciio",
> 0x0040);
> --
> 1.7.10.4
>
>
--
Regards,
Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu
; Add braces in cpu_memory_rw_debug.
> Avoid mixing var/code declarations in tcg_commit.
> Move per-cpu address space into CPUState.
> Reorder patch series to add the AS properties last.
--
Regards,
Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu
On Tue, Dec 31, 2013 at 2:43 AM, Peter Bartoli wrote:
>
> On Dec 28, 2013, at 2:00 AM, Artyom Tarasenko wrote:
>
> Actually QEMU does set variables in NVRAM (hw/sparc/sun4m.c:151), and
> afaik uses the layout of open-sourced OBP. The problem is that earlier
> versions of OB
d-off-by : Olivier Danet
Corresponds with http://www.squirrel.com/squirrel/sun-nvram-hostid.faq
and Solaris 9 detects the hostid after this patch fine, so
Reviewed-by: Artyom Tarasenko
> ---
> include/hw/nvram/openbios_firmware_abi.h | 2 ++
> 1 file changed, 2 insertions(+)
>
&
On Sat, Dec 28, 2013 at 6:52 PM, Mark Cave-Ayland
wrote:
> On 28/12/13 17:30, Artyom Tarasenko wrote:
>
>>> Also Artyom's blog is quite out of date with respect to OpenBIOS -
>>> OpenBIOS
>>> has been able to boot my test Solaris 8 image for over 2 years no
BP every time you restart).
Point taken. Added lists of Solaris kernels known to boot and not to
boot with OpenBIOS.
Feel free to submit yours if it's not in the lists yet. ;-)
Artyom
--
Regards,
Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu
om
> FW interface (which OBP has no knowledge of) rather than by having QEMU
> emulate the NVRAM in exactly the same way as real hardware.
Actually QEMU does set variables in NVRAM (hw/sparc/sun4m.c:151), and
afaik uses the layout of open-sourced OBP. The problem is that earlier
versions of OBP seemed to have a different layout, or maybe just a
magic constant is missing somewhere.
Artyom
--
Regards,
Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu
ime.
>
> Signed-off-by: Mark Cave-Ayland
> CC: Blue Swirl
> CC: Bob Breuer
> CC: Artyom Tarasenko
> ---
> Makefile |2 +-
> hw/display/tcx.c | 27 ++-
> hw/sparc/sun4m.c | 17 ++---
> pc-bios/QEM
persuade my
gcc (4.4.7) to use sse instructions for memcpy32.
Can't find my profiling results right now, but they were quite close to
Aurelien's ones[1]: tcg_optimize took nearly the same amount of time as
executing the translated code.
Artyom
1. http://www.mail-archive.com/qemu-devel@nongnu.org/msg171104.html
--
Regards,
Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu
On Thu, May 9, 2013 at 8:30 PM, Aurelien Jarno wrote:
> On Wed, May 08, 2013 at 11:02:24PM +0200, Artyom Tarasenko wrote:
>> On Wed, May 8, 2013 at 12:57 AM, Aurelien Jarno wrote:
>> > On Tue, May 07, 2013 at 11:29:20PM +0200, Artyom Tarasenko wrote:
>> >>
On Wed, May 8, 2013 at 12:57 AM, Aurelien Jarno wrote:
> On Tue, May 07, 2013 at 11:29:20PM +0200, Artyom Tarasenko wrote:
>> On Tue, May 7, 2013 at 1:38 PM, Torbjorn Granlund wrote:
>> > The 2nd table of http://gmplib.org/devel/testsystems.html shows all
>> > emulat
On Tue, May 7, 2013 at 11:43 PM, Torbjorn Granlund wrote:
> Artyom Tarasenko writes:
>
> Do I read it correct that qemu-system-ppc64 with the slowdown factor
> of 33 is ~3 times faster than qemu-system-sparc64 with the slowdown
> factor of 96 ?
>
> You read it correctl
n qemu-system-sparc64 with the slowdown
factor of 96 ?
Do they both use Debian Wheezy guest? You have a remark that ppc64 has
problems with its clock. Was it taken into account when the slowdown
factors were calculated?
Artyom
--
Regards,
Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog
On Fri, May 3, 2013 at 7:50 AM, Hervé Poussineau wrote:
> Artyom Tarasenko a écrit :
>
>> On Thu, May 2, 2013 at 10:09 PM, Hervé Poussineau
>> wrote:
>>>
>>> As m48t59 devices can only be created with m48t59_init() or
>>> m48t59_init_isa(),
>&
nfo = {
> +.name = TYPE_M48TXX_SYS_BUS,
> +.parent = TYPE_SYS_BUS_DEVICE,
> +.instance_size = sizeof(M48txxSysBusState),
> +.abstract = true,
> +.class_init = m48txx_sysbus_class_init,
> +};
> +
> +static const TypeInfo m48txx_isa_type_info = {
> +.nam
On Mon, Apr 29, 2013 at 7:43 AM, Rob Landley wrote:
> On 04/27/2013 03:00:06 PM, Artyom Tarasenko wrote:
>>
>> > For a lot of the 64-bit targets, actual 64 bit userspace support is
>> > strangely lacking. For ppc64 they say to use ppc32, and I've been told
>>
;t really recompile this exact version, but you can recompile a
> slightly older version, the one which is in the Debian archive:
>
> http://packages.debian.org/source/unstable/openhackware
>
> I don't know what are the difference between this one and the one in
> QEMU though.
Fwiw last year I built ppc_rom.bin from this git tree:
git://github.com/tycho/openhackware.git
Saw no differences between this one and the binary one while booting Linux.
Artyom
--
Regards,
Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu
301 - 400 of 701 matches
Mail list logo
