On 07/20/2017 01:23 PM, Emilio G. Cota wrote:
That's a nice helper -- will do it this way.
For v4, should I send all patches again, or just the handful of patches
that are changing from v3?
I don't mind if you just send the changed patches.
Just be sure to reference the tree in the cover lette
On Thu, Jul 20, 2017 at 11:22:10 -1000, Richard Henderson wrote:
> >Perhaps we should then enlarge both the first and last regions so that we
> >fully use the buffer.
>
> I really like the idea. That's a lot of space recovered for 64k page hosts.
>
> I do think we can make the computation cleare
On 07/20/2017 10:50 AM, Emilio G. Cota wrote:
On Wed, Jul 19, 2017 at 22:04:50 -1000, Richard Henderson wrote:
On 07/19/2017 05:09 PM, Emilio G. Cota wrote:
+/* We do not yet support multiple TCG contexts, so use one region for now
*/
+n_regions = 1;
+
+/* start on a page-aligned a
On Wed, Jul 19, 2017 at 22:04:50 -1000, Richard Henderson wrote:
> On 07/19/2017 05:09 PM, Emilio G. Cota wrote:
> >+/* We do not yet support multiple TCG contexts, so use one region for
> >now */
> >+n_regions = 1;
> >+
> >+/* start on a page-aligned address */
> >+buf = QEMU_ALIG
On 07/19/2017 05:09 PM, Emilio G. Cota wrote:
+/* We do not yet support multiple TCG contexts, so use one region for now
*/
+n_regions = 1;
+
+/* start on a page-aligned address */
+buf = QEMU_ALIGN_PTR_UP(buf, qemu_real_host_page_size);
+g_assert(buf < tcg_init_ctx.code_gen_
This is groundwork for supporting multiple TCG contexts.
The naive solution here is to split code_gen_buffer statically
among the TCG threads; this however results in poor utilization
if translation needs are different across TCG threads.
What we do here is to add an extra layer of indirection, a
