Peter Maydell writes:
> On Thu, 12 Sep 2019 at 11:07, Alex Bennée wrote:
>> Peter Maydell writes:
>> > Wait, what? From my perspective the whole point of the plugin
>> > interface is that it should be stable, in that at least there's
>> > a good chance that a plugin you built will work agains
On Thu, 12 Sep 2019 at 11:17, Daniel P. Berrangé wrote:
> I think forcing recompile for each release is reasonable protection
> to make it less atttractive to create license violating closed source
> plugins.
I'm just not sure that a plugin that, for instance, does
"whenever the guest makes a mem
On Thu, 12 Sep 2019 at 11:07, Alex Bennée wrote:
> Peter Maydell writes:
> > Wait, what? From my perspective the whole point of the plugin
> > interface is that it should be stable, in that at least there's
> > a good chance that a plugin you built will work against multiple
> > versions of QEMU,
On Thu, Sep 12, 2019 at 11:07:07AM +0100, Alex Bennée wrote:
>
> Peter Maydell writes:
>
> > On Thu, 12 Sep 2019 at 10:03, Alex Bennée wrote:
> >>
> >> Well the first thing will be we are not intending to offer a guaranteed
> >> ABI. While we don't want to be changing it at a whim there shouldn
Peter Maydell writes:
> On Thu, 12 Sep 2019 at 10:03, Alex Bennée wrote:
>>
>> Well the first thing will be we are not intending to offer a guaranteed
>> ABI. While we don't want to be changing it at a whim there shouldn't be
>> an expectation that the plugin interface will maintain backwards
On Thu, Sep 12, 2019 at 10:03:48AM +0100, Alex Bennée wrote:
>
> Markus Armbruster writes:
>
> > Alex Bennée writes:
> >
> >> Markus Armbruster writes:
> > [...]
> >>> Please advise why TCG plugins don't undermine the GPL. Any proposal to
> >>> add a plugin interface needs to do that.
> >>
>
On Thu, 12 Sep 2019 at 10:03, Alex Bennée wrote:
>
> Well the first thing will be we are not intending to offer a guaranteed
> ABI. While we don't want to be changing it at a whim there shouldn't be
> an expectation that the plugin interface will maintain backwards
> compatibility (unlike the comm
Markus Armbruster writes:
> Alex Bennée writes:
>
>> Markus Armbruster writes:
> [...]
>>> Please advise why TCG plugins don't undermine the GPL. Any proposal to
>>> add a plugin interface needs to do that.
>>
>> I'm not sure what we can say about this apart from "ask your lawyer".
>
> I'm n
Alex Bennée writes:
> Markus Armbruster writes:
[...]
>> Please advise why TCG plugins don't undermine the GPL. Any proposal to
>> add a plugin interface needs to do that.
>
> I'm not sure what we can say about this apart from "ask your lawyer".
I'm not asking for a legal argument, I'm asking
All,
Submitting proposal :
Per Power ISA 3.02B Book III at pages 1029 and 1030, bit 15 of the
slbmfee and slbmfev instructions is now assigned to an implementation
specific bit and is no longer reserved - meaning it can be set to 1 but
can probably be safely ignored.
2.07B still indicates b
On 12/10/18 8:37 AM, Ancuta, Cristian wrote:
> Hi,
>
> Hope this is the right place for this question.
>
> I was wondering whether the TCG i386 backend is currently able to generate
> SIMD code ( vector loads/store, moves, vector arithmetic, etc ).
Yes, it is.
> Looking around on patchwork I f
Hi,
Hope this is the right place for this question.
I was wondering whether the TCG i386 backend is currently able to generate SIMD
code ( vector loads/store, moves, vector arithmetic, etc ).
Looking around on patchwork I found these patches:
https://patchwork.kernel.org/project/qemu-devel/lis
Hello Richard,
the case INDEX_op_dup_vec in optimize.c:tcg_optimize is doing a break
when the input arg is not constant instead of jumping to do_default.
The issue can be reproduced by compiling the following SVE code:
.global main
.section .text
main:
mov z2.d, #0
decpz
On 06/13/2018 03:54 PM, Emilio G. Cota wrote:
> So, what to do based on all this?
>
> I think the current implementation makes sense. That said, two
> things we could consider doing are:
Thanks for checking.
> - Remove the guard pages. I'd rather keep them in though, since
> their cost is neg
After a discussion with Richard yesterday on IRC, I ran some numbers on the
performance impact of the guard pages added at the end of TCG regions.
These 4kB guard pages prevent the use of transparent huge pages for the
last 2MB of a region.
The benchmark I used is the bootup+shutdown of debian on
On 05/22/2018 09:31 AM, Peter Maydell wrote:
> Do we also want f16 inputs to mean uint32_t arguments?
Yes. We don't want the compiler assuming zeros (for non-x86 abis) when we
aren't providing them.
r~
On 22 May 2018 at 17:27, Richard Henderson wrote:
> On 05/22/2018 09:19 AM, Peter Maydell wrote:
>> But what we actually have is
>> target/arm/helper.c:float16 HELPER(recpe_f16)(float16 input, void *fpstp)
>> target/arm/helper.c:float16 HELPER(vfp_sltoh)(uint32_t x, uint32_t
>> shift, void *fpst)
On 05/22/2018 09:19 AM, Peter Maydell wrote:
> But what we actually have is
> target/arm/helper.c:float16 HELPER(recpe_f16)(float16 input, void *fpstp)
> target/arm/helper.c:float16 HELPER(vfp_sltoh)(uint32_t x, uint32_t
> shift, void *fpst)
>
> (and others that you can find by grepping for "float
On 22 May 2018 at 17:11, Richard Henderson wrote:
> On 05/22/2018 07:56 AM, Peter Maydell wrote:
> The *helpers* are supposed to be returning uint32_t. That should be enforced
> by the prototype generated from "f16" being aliased to "i32".
>
> The softfloat routines are supposed to be returning f
On 05/22/2018 07:56 AM, Peter Maydell wrote:
>>> However, for TCG helper functions, although we allow the helper
>>> macro to say that the return type is 'f16', in helper-head.h we
>>> seem to just alias f16 as i32, and in dh_sizemask() we only record
>>> "is this 64 bits" and "is this signed". Am
On 22 May 2018 at 15:55, Richard Henderson wrote:
> On 05/22/2018 07:50 AM, Peter Maydell wrote:
>> Hi; I was reading about the x86-64 calling convention and I found
>> out that apparently for returns of smaller-than-register types the
>> high parts may contain garbage:
>> https://stackoverflow.co
On 05/22/2018 07:50 AM, Peter Maydell wrote:
> Hi; I was reading about the x86-64 calling convention and I found
> out that apparently for returns of smaller-than-register types the
> high parts may contain garbage:
> https://stackoverflow.com/questions/36706721/is-a-sign-or-zero-extension-required
Hi; I was reading about the x86-64 calling convention and I found
out that apparently for returns of smaller-than-register types the
high parts may contain garbage:
https://stackoverflow.com/questions/36706721/is-a-sign-or-zero-extension-required-when-adding-a-32bit-offset-to-a-pointer-for/36760539
- Original Message -
> From: "Peter Maydell"
> To: "Paolo Bonzini"
> Cc: "QEMU Developers" , "Alex Bennée"
> , "Richard Henderson"
> , "Emilio G. Cota" , "Pavel Dovgalyuk"
>
> Sent: Thursday, April 5, 2018 7:35:56 PM
> Subject: Re: TCG icount interaction with timer deadlines
>
> On
On 5 April 2018 at 18:07, Paolo Bonzini wrote:
> On 05/04/2018 18:01, Peter Maydell wrote:
>> * however, if the guest reprograms the clock during the tcg_cpu_exec()
>>run, we don't do anything to cause us to stop earlier
>
> Anything that does this from the vCPU thread should be between
> gen
On 05/04/2018 18:01, Peter Maydell wrote:
> * however, if the guest reprograms the clock during the tcg_cpu_exec()
>run, we don't do anything to cause us to stop earlier
Anything that does this from the vCPU thread should be between
gen_icount_start and gen_icount_end. (In fact, it's the ent
Does anybody understand how icount TCG is supposed to arrange to
respect timer deadlines?
https://bugs.launchpad.net/qemu/+bug/1754038 has a test case which
shows that we don't get this right.
At the moment what happens is:
* when we're about to call tcg_cpu_exec(), we call
prepare_icount_for
Hello,
I'm looking at adding support for MicroBlaze extended addressing
allowing 32bit cores to reach a 64-bit address space.
The ABI for MicroBlaze remains 32-bits. It's basically a PAE-like
MMU extension + a new set of extended address Load/Store instructions
for the non-MMU mode.
I'm primaril
https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg04321.html
This patch causes problems with Mac OS 10.6. It stops compilation. This is the
error I see when I try to compile the code:
tcg/i386/tcg-target.inc.c:3495:no such instruction: `xgetbv`
This is the code that causes the problem:
On 6 October 2017 at 18:36, Peter Maydell wrote:
> Running the test program
> http://people.linaro.org/~peter.maydell/thumb-over-page
> (source at http://people.linaro.org/~peter.maydell/thumb-over-page.c)
> in the usermode emulator:
> ./build/x86/arm-linux-user/qemu-arm ~/linaro/qemu-misc-tests/
On 10 October 2017 at 11:54, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> On 10 October 2017 at 10:53, Alex Bennée wrote:
>>>
>>> Peter Maydell writes:
>>>
Running the test program
http://people.linaro.org/~peter.maydell/thumb-over-page
(source at http://people.linaro.org/~p
On 10/10/2017 12:52, Peter Maydell wrote:
> On 10 October 2017 at 11:41, Paolo Bonzini wrote:
>> I've seen the same on x86. Using the program counter from translate.c
>> here looks very fishy:
>>
>> /* Now we have a real cpu fault. Since this is the exact location of
>> * the exception,
Peter Maydell writes:
> On 10 October 2017 at 10:53, Alex Bennée wrote:
>>
>> Peter Maydell writes:
>>
>>> Running the test program
>>> http://people.linaro.org/~peter.maydell/thumb-over-page
>>> (source at http://people.linaro.org/~peter.maydell/thumb-over-page.c)
>>> in the usermode emulator
On 10 October 2017 at 11:41, Paolo Bonzini wrote:
> I've seen the same on x86. Using the program counter from translate.c
> here looks very fishy:
>
> /* Now we have a real cpu fault. Since this is the exact location of
> * the exception, we must undo the adjustment done by cpu_restore_
On 10/10/2017 12:07, Peter Maydell wrote:
> On 10 October 2017 at 10:53, Alex Bennée wrote:
>>
>> Peter Maydell writes:
>>
>>> Running the test program
>>> http://people.linaro.org/~peter.maydell/thumb-over-page
>>> (source at http://people.linaro.org/~peter.maydell/thumb-over-page.c)
>>> in the
On 10 October 2017 at 10:53, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> Running the test program
>> http://people.linaro.org/~peter.maydell/thumb-over-page
>> (source at http://people.linaro.org/~peter.maydell/thumb-over-page.c)
>> in the usermode emulator:
>> ./build/x86/arm-linux-user/q
Peter Maydell writes:
> Running the test program
> http://people.linaro.org/~peter.maydell/thumb-over-page
> (source at http://people.linaro.org/~peter.maydell/thumb-over-page.c)
> in the usermode emulator:
> ./build/x86/arm-linux-user/qemu-arm
> ~/linaro/qemu-misc-tests/thumb-over-page
Does t
Running the test program
http://people.linaro.org/~peter.maydell/thumb-over-page
(source at http://people.linaro.org/~peter.maydell/thumb-over-page.c)
in the usermode emulator:
./build/x86/arm-linux-user/qemu-arm ~/linaro/qemu-misc-tests/thumb-over-page
results in an assertion failure:
write_insn
On 6 February 2017 10:39:11 GMT+00:00, Peter Maydell
wrote:
>On 6 February 2017 at 10:14, Ed Robbins wrote:
>> It seems pretty good. I was surprised that call instructions can
>> have arguments/return specified, and wonder if those are normally
>> just empty, so that emulation of the target st
On 6 February 2017 at 10:14, Ed Robbins wrote:
> It seems pretty good. I was surprised that call instructions can
> have arguments/return specified, and wonder if those are normally
> just empty, so that emulation of the target stack/registers just
> carries the args/return in the background. Othe
On 3 February 2017 14:46:15 GMT+00:00, Stefan Hajnoczi
wrote:
>On Thu, Feb 02, 2017 at 12:09:02PM +, E.Robbins wrote:
>> I having been looking for prior work on a formalised semantics for
>the TCG language. I have seen passing references, and wondered if
>anyone can provide any pointers?
>>
On Thu, Feb 02, 2017 at 12:09:02PM +, E.Robbins wrote:
> I having been looking for prior work on a formalised semantics for the TCG
> language. I have seen passing references, and wondered if anyone can provide
> any pointers?
>
> If this is the wrong list for this question, apologies, pleas
Hello,
I having been looking for prior work on a formalised semantics for the TCG
language. I have seen passing references, and wondered if anyone can provide
any pointers?
If this is the wrong list for this question, apologies, please direct me
elsewhere.
Best,
Ed
Hello all,
the last bug report from Alex pointed me to the fact that I am unable to focus
on TCG AArch64 maintenance, due to changed working conditions since some time
now.
I think that in practice Richard has been taking care of this module anyway, so
I think it is time to make it official.
S
On 07/31/2016 05:23 AM, Benjamin Herrenschmidt wrote:
The first obvious thing that comes to mind is to avoid stopping the
TB on a non-taken conditional branch. The reason that can't be done
today, from my limited understanding of things, is because we only
support index 0 and 1 today for gen_goto
Hi Richard !
So in my discovery of TCG, one thing I noticed is the horrendous amount
of code generated for branches, especially conditional ones.
I have a patch at least to remove a bunch of dead gunk on target-ppc
for non-conditional ones (we still generated the "else" of the
condition even when
On Tue, 2016-07-26 at 08:42 +1000, Benjamin Herrenschmidt wrote:
> We do something a bit different on ppc where we store the access type
> before every access, however the DSISR case is special in that on
> older
> CPUs, it's expected to contains a whole subset of the opcode which is
> quite a bit
On Mon, 2016-07-25 at 23:19 +0100, Peter Maydell wrote:
> > For example we have one in powerpc_excp() to read the faulting
> > instruction, though that *should* never fail it's till not great.
>
> Mmm. Strictly speaking you can't guarantee that that load will
> work, because the code you're execut
On 25 July 2016 at 22:42, Benjamin Herrenschmidt
wrote:
> On Mon, 2016-07-25 at 19:30 +0530, Richard Henderson wrote:
>> > Or can they also be called outside of that context ?
>>
>> No, not without a valid return address.
>>
>> E.g. it's not valid to have one helper call another, and for the secon
On Mon, 2016-07-25 at 19:42 +0530, Richard Henderson wrote:
> For some targets, we also restore part of the flags computation with this
> mechanism. With more trickery, ARM is (intending to?) compute exception
> syndrome information with this. As I understand it, this is very much akin
> to
>
On Mon, 2016-07-25 at 19:30 +0530, Richard Henderson wrote:
> > Or can they also be called outside of that context ?
>
> No, not without a valid return address.
>
> E.g. it's not valid to have one helper call another, and for the second
> helper
> use GETPC. For this, typically, one must facto
On 07/25/2016 10:45 AM, Benjamin Herrenschmidt wrote:
On Mon, 2016-07-25 at 06:04 +0530, Richard Henderson wrote:
I noticed a related problem recently, while working on the cmpxchg patch set.
In my opinion, we should (1) merge GETRA and GETPC so there's no confusion
between the two, (2) push al
On 07/25/2016 06:21 AM, Benjamin Herrenschmidt wrote:
On Mon, 2016-07-25 at 10:46 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2016-07-25 at 06:06 +0530, Richard Henderson wrote:
These functions would have to be always_inline for this to work.
Otherwise you
could get the helper's PC, not the T
On Mon, 2016-07-25 at 06:04 +0530, Richard Henderson wrote:
> I noticed a related problem recently, while working on the cmpxchg patch set.
>
> In my opinion, we should (1) merge GETRA and GETPC so there's no confusion
> between the two, (2) push all adjustment down to the final moment before use
On Mon, 2016-07-25 at 10:46 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2016-07-25 at 06:06 +0530, Richard Henderson wrote:
> >
> > These functions would have to be always_inline for this to work.
> > Otherwise you
> > could get the helper's PC, not the TCG caller's PC.
> >
> > But let's try
On Mon, 2016-07-25 at 06:06 +0530, Richard Henderson wrote:
> These functions would have to be always_inline for this to work.
> Otherwise you
> could get the helper's PC, not the TCG caller's PC.
>
> But let's try to fix this the other way.
I could use some help there as I don't really underst
On 07/24/2016 06:22 PM, Benjamin Herrenschmidt wrote:
On Sun, 2016-07-24 at 22:51 +1000, Benjamin Herrenschmidt wrote:
>
> FYI: This probably completely wrong patch (but it was easier than
> hacking all the helpers) fixed the problem for me. With this (and the
> video driver I wrote that I will
On 07/24/2016 06:12 PM, Benjamin Herrenschmidt wrote:
Hi !
I need help from TCG experts here. I was chasing down a bug causing
some stuff to crash when using vector ops with a ppc32 guest on x86,
but pulling that string led to a whole mess that *may* be affecting a
pile of architetures unless I'
On Sun, 2016-07-24 at 22:51 +1000, Benjamin Herrenschmidt wrote:
>
> FYI: This probably completely wrong patch (but it was easier than
> hacking all the helpers) fixed the problem for me. With this (and the
> video driver I wrote that I will publish asap), I can now reliably
> boot
> various versi
On Sun, 2016-07-24 at 22:42 +1000, Benjamin Herrenschmidt wrote:
>
> What *did* work was to copy what x86 does, which is to change my
> helper_stvebx() to not use cpu_stb_data at all, but instead use
> cpu_stb_data_ra(, GETPC()), which mimmics what x86 does for some
> of
> it's helpers.
>
> T
Hi !
I need help from TCG experts here. I was chasing down a bug causing
some stuff to crash when using vector ops with a ppc32 guest on x86,
but pulling that string led to a whole mess that *may* be affecting a
pile of architetures unless I'm misunderstanding something...
So basically what happe
On 15/05/16 23:54, Sergey Fedorov wrote:
> On 15/05/16 22:56, Sergey Fedorov wrote:
>> On 15/05/16 22:53, Max Filippov wrote:
>>> On Sun, May 15, 2016 at 10:38:46PM +0300, Sergey Fedorov wrote:
On 15/05/16 21:58, Max Filippov wrote:
> I've noticed that the commit 5b053a4a28278 (tcg: Clean
On 15/05/16 22:56, Sergey Fedorov wrote:
> On 15/05/16 22:53, Max Filippov wrote:
>> On Sun, May 15, 2016 at 10:38:46PM +0300, Sergey Fedorov wrote:
>>> On 15/05/16 21:58, Max Filippov wrote:
I've noticed that the commit 5b053a4a28278 (tcg: Clean up direct block
chaining safety checks) ha
On 15/05/16 22:53, Max Filippov wrote:
> On Sun, May 15, 2016 at 10:38:46PM +0300, Sergey Fedorov wrote:
>> On 15/05/16 21:58, Max Filippov wrote:
>>> I've noticed that the commit 5b053a4a28278 (tcg: Clean up direct block
>>> chaining safety checks) has broken tearget-xtensa test cross_page_tb
>>>
On Sun, May 15, 2016 at 10:38:46PM +0300, Sergey Fedorov wrote:
> On 15/05/16 21:58, Max Filippov wrote:
> > I've noticed that the commit 5b053a4a28278 (tcg: Clean up direct block
> > chaining safety checks) has broken tearget-xtensa test cross_page_tb
> > from the tests/tcg/xtensa/test_mmu.S. The
On 15/05/16 21:58, Max Filippov wrote:
> Hi Sergey,
>
> I've noticed that the commit 5b053a4a28278 (tcg: Clean up direct block
> chaining safety checks) has broken tearget-xtensa test cross_page_tb
> from the tests/tcg/xtensa/test_mmu.S. The test runs a TB that spans two
> adjacent pages, then unma
Hi Sergey,
I've noticed that the commit 5b053a4a28278 (tcg: Clean up direct block
chaining safety checks) has broken tearget-xtensa test cross_page_tb
from the tests/tcg/xtensa/test_mmu.S. The test runs a TB that spans two
adjacent pages, then unmaps the second page and runs it again. It
expects a
On 03/05/16 03:02, Peter Maydell wrote:
> On 2 May 2016 at 21:18, Sergey Fedorov wrote:
>> On 02/05/16 22:54, Sergey Fedorov wrote:
>>
>> Hi,
>>
>> I can't figure out how this field is used. The comment says it's "Currently
>> executing TB", but actually it's the first TB in a chain of TBs execute
On 2 May 2016 at 21:18, Sergey Fedorov wrote:
> On 02/05/16 22:54, Sergey Fedorov wrote:
>
> Hi,
>
> I can't figure out how this field is used. The comment says it's "Currently
> executing TB", but actually it's the first TB in a chain of TBs executed.
> Grep shows the only place it is really chec
On 02/05/16 22:54, Sergey Fedorov wrote:
> Hi,
>
> I can't figure out how this field is used. The comment says it's
> "Currently executing TB", but actually it's the first TB in a chain of
> TBs executed. Grep shows the only place it is really checked is
> tb_invalidate_phys_page_range(). That code
Hi,
I can't figure out how this field is used. The comment says it's
"Currently executing TB", but actually it's the first TB in a chain of
TBs executed. Grep shows the only place it is really checked is
tb_invalidate_phys_page_range(). That code seems to be introduced long
ago in:
commit ea1
On Wed, Apr 27, 2016 at 08:57:24AM +0200, Aurelien Jarno wrote:
> On 2016-04-26 20:12, Guenter Roeck wrote:
> > Hi,
> >
> > when running qemu version 2.6.0-rc3, I get the following error message.
> >
> > /opt/buildbot/qemu/qemu/tcg/tcg.c:1769: tcg fatal error
> >
> > qemu command line is as foll
On 2016-04-26 20:12, Guenter Roeck wrote:
> Hi,
>
> when running qemu version 2.6.0-rc3, I get the following error message.
>
> /opt/buildbot/qemu/qemu/tcg/tcg.c:1769: tcg fatal error
>
> qemu command line is as follows.
>
> qemu-system-ppc64 -M mpc8544ds \
> -cpu e5500 \
> -m 1024
Hi,
when running qemu version 2.6.0-rc3, I get the following error message.
/opt/buildbot/qemu/qemu/tcg/tcg.c:1769: tcg fatal error
qemu command line is as follows.
qemu-system-ppc64 -M mpc8544ds \
-cpu e5500 \
-m 1024 -kernel arch/powerpc/boot/uImage -initrd busybox-ppc.cpio \
On 01/04/16 14:11, Alex Bennée wrote:
> Sergey Fedorov writes:
>
>> On 31/03/16 16:37, Alex Bennée wrote:
>>> Sergey Fedorov writes:
Looks like no matter which approach we use, it's ultimately necessary to
ensure all CPUs have exited from translated code before the translation
buff
Sergey Fedorov writes:
> On 31/03/16 16:37, Alex Bennée wrote:
>> Sergey Fedorov writes:
>>> Looks like no matter which approach we use, it's ultimately necessary to
>>> ensure all CPUs have exited from translated code before the translation
>>> buffer may be safely flushed.
>> One approach wou
On 31/03/2016 21:03, Sergey Fedorov wrote:
> Looks like we have to ensure all vCPUs are out of translated code when
> doing TB patching either doing tb_add_jump() or tb_phys_invalidate().
> Did I missed something?
Almost all TCG targets have naturally aligned instructions, so that's
not a proble
On 31/03/16 17:06, Sergey Fedorov wrote:
> It should be safe to invalidate a TB while some other CPU is executing
> its translated code.
Probably it's not safe to invalidate a TB while some other thread is
executing the translated code. Direct jumps to the TB being invalidated
should be reset. In
On 03/31/2016 10:30 AM, Peter Maydell wrote:
> On 24 March 2016 at 11:09, Peter Maydell wrote:
>> On 24 March 2016 at 10:55, Sergey Fedorov wrote:
>>> Probably we don't have a maintainer for PPC TCG backend.
>>>
>>> PPC
>>> M: Vassili Karpov (malc)
>>> S: Maintained
>>> F: tcg/pp
On 24 March 2016 at 11:09, Peter Maydell wrote:
> On 24 March 2016 at 10:55, Sergey Fedorov wrote:
>> Probably we don't have a maintainer for PPC TCG backend.
>>
>> PPC
>> M: Vassili Karpov (malc)
>> S: Maintained
>> F: tcg/ppc/
>> F: disas/ppc.c
>
> Yes, malc has not been wi
On 03/31/2016 05:42 AM, Sergey Fedorov wrote:
> On 31/03/16 13:48, Alex Bennée wrote:
>> I know we are system focused at the moment but does linux-user ever
>> flush groups of TBs, say when mappings change? Or does this trigger a
>> whole tb_flush?
>
> Yes, e.g. target_mmap() calls tb_invalidate_p
On 31/03/2016 16:35, Sergey Fedorov wrote:
>> > My plan was to use some kind of double buffering, where only half of
>> > code_gen_buffer is in use. At the end of tb_flush you call cpu_exit()
>> > on all CPUs, so that CPUs stop executing chained TBs from the old half
>> > before they can see one
On 31/03/16 16:40, Paolo Bonzini wrote:
>
> On 31/03/2016 15:14, Sergey Fedorov wrote:
>> On 30/03/16 21:13, Paolo Bonzini wrote:
>>> On 30/03/2016 19:08, Sergey Fedorov wrote:
The second approach is to make 'tb_invalidated_flag' per-CPU. This
would be conceptually similar to what we have
On 31/03/16 16:37, Alex Bennée wrote:
> Sergey Fedorov writes:
>> Looks like no matter which approach we use, it's ultimately necessary to
>> ensure all CPUs have exited from translated code before the translation
>> buffer may be safely flushed.
> One approach would be to have multiple translatio
On 31/03/2016 15:14, Sergey Fedorov wrote:
> On 30/03/16 21:13, Paolo Bonzini wrote:
>>
>> On 30/03/2016 19:08, Sergey Fedorov wrote:
>>> The second approach is to make 'tb_invalidated_flag' per-CPU. This
>>> would be conceptually similar to what we have, but would give us thread
>>> safety. With
Sergey Fedorov writes:
> On 30/03/16 21:13, Paolo Bonzini wrote:
>>
>> On 30/03/2016 19:08, Sergey Fedorov wrote:
>>> The second approach is to make 'tb_invalidated_flag' per-CPU. This
>>> would be conceptually similar to what we have, but would give us thread
>>> safety. With this approach, we
On 30/03/16 21:13, Paolo Bonzini wrote:
>
> On 30/03/2016 19:08, Sergey Fedorov wrote:
>> The second approach is to make 'tb_invalidated_flag' per-CPU. This
>> would be conceptually similar to what we have, but would give us thread
>> safety. With this approach, we need to be careful to correctly c
On 31/03/16 13:48, Alex Bennée wrote:
> I know we are system focused at the moment but does linux-user ever
> flush groups of TBs, say when mappings change? Or does this trigger a
> whole tb_flush?
Yes, e.g. target_mmap() calls tb_invalidate_phys_range().
Kind regards,
Sergey
Sergey Fedorov writes:
> Hi,
>
> This is a follow-up of the discussion [1]. The main focus is to move
> towards thread-safe TB invalidation and translation buffer flush.
> In addition, we can get more clean, readable and reliable code.
>
> First, I'd like to summarize how 'tb_invalidated_flag' i
On 30/03/16 22:08, Richard Henderson wrote:
> On 03/30/2016 10:08 AM, Sergey Fedorov wrote:
>> As of catching tb_flush() in cpu_exec() there have been three approaches
>> proposed.
>>
>> The first approach is to get rid of 'tb_invalidated_flag' and use
>> 'tb_flush_count'. Capture 'tb_flush_count'
On 03/30/2016 10:08 AM, Sergey Fedorov wrote:
> As of catching tb_flush() in cpu_exec() there have been three approaches
> proposed.
>
> The first approach is to get rid of 'tb_invalidated_flag' and use
> 'tb_flush_count'. Capture 'tb_flush_count' inside 'tb_lock' critical
> section of cpu_exec()
On 30/03/2016 19:08, Sergey Fedorov wrote:
> cpu_exec() case is a bit more subtle. Regarding tb_phys_invalidate(), it
> shouldn't be harmful if an invalidated TB get patched because it is not
> going to be executed anymore. It may only be a concern of efficiency.
> Though it doesn't seem to happe
Hi,
This is a follow-up of the discussion [1]. The main focus is to move
towards thread-safe TB invalidation and translation buffer flush.
In addition, we can get more clean, readable and reliable code.
First, I'd like to summarize how 'tb_invalidated_flag' is used.
Basically, 'tb_invalidated_fla
On 14/03/2016 16:26, Pranith Kumar wrote:
> I am trying to understand what scenarios can result in no TBs
> executing for that CPU. My understanding is that there is a pending
> operation which needs to be handled before we can execute TBs from
> this CPU(I/O?).
For example the CPU could be halt
On 24 March 2016 at 10:55, Sergey Fedorov wrote:
> Hi Peter,
>
> Probably we don't have a maintainer for PPC TCG backend.
>
> PPC
> M: Vassili Karpov (malc)
> S: Maintained
> F: tcg/ppc/
> F: disas/ppc.c
Yes, malc has not been with the project for some years now. We
should pr
Hi Peter,
Probably we don't have a maintainer for PPC TCG backend.
PPC
M: Vassili Karpov (malc)
S: Maintained
F: tcg/ppc/
F: disas/ppc.c
Kind regards,
Sergey
Forwarded Message
Subject:Delivery Status Notification (Failure)
Date: Thu, 24 Mar 2016
Hello Paolo,
I have a question reg. tcg_cpu_exec(cpu) which is called from tcg_exec_all().
tcg_cpu_exec() is called for each cpu in a loop. I observed that this
call does not always execute TBs on that particular CPU. It return
because the exit_request is set.
I am trying to understand what scen
On (Fri) 04 Dec 2015 [01:43:07], Li, Liang Z wrote:
> >
> > Thanks for describing how to reproduce the bug.
> > If some pages are not transferred to destination then it is a bug, so we
> > need
> > to know what the problem is, notice that the problem can be that TCG is not
> > marking dirty some
On 12/11/2015 05:41 AM, Peter Maydell wrote:
Hi; I noticed while grepping through code that the version of
tcg_liveness_analysis() in tcg/tcg.c for #ifndef USE_LIVENESS_ANALYSIS
won't compile because it's still referring to the no-longer-existent
TCGContext::gen_opc_buf.
Oops.
Richard, I thin
Hi; I noticed while grepping through code that the version of
tcg_liveness_analysis() in tcg/tcg.c for #ifndef USE_LIVENESS_ANALYSIS
won't compile because it's still referring to the no-longer-existent
TCGContext::gen_opc_buf.
Richard, I think this was probably broken as part of your changes to
us
1 - 100 of 316 matches
Mail list logo
