qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: Taylor Simpson <tsimpson@quicinc.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "ale@rev.ng" <ale@rev.ng>,
	"riku.voipio@iki.fi" <riku.voipio@iki.fi>,
	"philmd@redhat.com" <philmd@redhat.com>,
	"laurent@vivier.eu" <laurent@vivier.eu>,
	"aleksandar.m.mail@gmail.com" <aleksandar.m.mail@gmail.com>
Subject: Re: [RFC PATCH v3 31/34] Hexagon (target/hexagon) translation
Date: Sun, 30 Aug 2020 16:08:20 -0700	[thread overview]
Message-ID: <a8f99274-a865-0ffb-d49b-648e8be8170c@linaro.org> (raw)
In-Reply-To: <BYAPR02MB488647E77E043F2A20CEF007DE500@BYAPR02MB4886.namprd02.prod.outlook.com>

On 8/30/20 12:37 PM, Taylor Simpson wrote:
> I'm actually checking two conditions here.
> 1) packet crossing a page boundary
> 2) reading too many words without finding the end of the packet.
> I guess it would be better to separate them.
> 
> What is the correct behavior for the second case?  Should we return an error code from here and have the higher level code generate the invalid packet exception?

I would return an error code.

In fact, I would also pass in the max number of words to read:

static int read_packet_words(CPUHexagonState *env,
                             DisasContext *ctx,
                             uint32_t words[PACKET_WORDS_MAX],
                             int max_words)
{
   // stuff
   return !found_end ? 0 : nwords;
}


Then, in translate_packet,


    uint32_t words[PACKET_WORDS_MAX];
    int nwords = read_packet_words(env, ctx, words,
                                   PACKET_WORDS_MAX);

    if (nwords == 0) {
        // raise exception
        return;
    }

    decode_and_translate_packet(env, ctx, words, nwords);

    /* If we're going to try for another packet... */
    if (ctx->base.is_jmp == DISAS_NEXT &&
        ctx->base.num_insns < ctx->base.num_insns) {
        /*
         * Remember the end of the page containing the
         * first packet.  Note that the first packet
         * is allowed to span two pages, so this is not
         * necessarily the same as the end of the page
         * containing ctx->base.pc_start.
         */
        if (ctx->base.num_insns == 1) {
            ctx->page_end
                = TARGET_PAGE_ALIGN(ctx->base.pc_next);
        }

        /*
         * If there are not PACKET_WORDS_MAX remaining on
         * the page, check to see if a full packet remains.
         * If not, split the TB so that the packet that
         * crosses the page begins the next TB.
         */
        target_long left = ctx->page_end - ctx->base.pc_next;
        tcg_debug_assert(left >= 0);
        if (left == 0
            || (left < PACKET_WORDS_MAX * 4 &&
                !read_packet_words(env, ctx, words, left / 4)) {
            ctx->base.is_jmp = DISAS_TOO_MANY;
        }
    }


The reason for all this is to properly capture the behaviour of instruction
execution vs SIGSEGV.

First, during translate we do not want to read from the next page unless
absolutely necessary.  Doing so could raise SIGSEGV before it would be
appropriate, e.g. because the TB should have branched away (or raised SIGFPE,
or anything else) before getting that far.

Second, when dispatching a TB, we check the 1 or 2 pages that the TB occupies
for validity.  If the second page is invalid, we raise SIGSEGV without
executing the TB at all.  Which makes it appear as if the SIGSEGV happened at
the first insn of the TB.  Which is correct if and only if the first insn is
the one that did cross the page.

>> Surely you don't need to actually set PC for every PC?
> 
> What do other targets do?

If you have a pc-relative instruction, e.g. x86_64's

  lea  offset(%rip), %rax

then you just use the known immediate for %rip:

  tcg_gen_movi_tl(cpu_reg[eax], ctx->base.pc_next + offset);

Normally, PC is only valid when explicitly returning to the cpu loop
(tcg_gen_exit_tb, static exception), for indirect branching
(tcg_gen_lookup_and_goto_ptr), or after dynamic exception unwinding
(restore_state_to_opc).

When using goto_tb, we can get away with *assuming* static state, because the
values get baked into the link to a specific next-TB.  That's why the general
form is

  tcg_gen_goto_tb(n);
  gen_set_pc_im(s, dest);
  tcg_gen_exit_tb(s->base.tb, n);

The first time we cross link N, the link is unset, which causes the goto_tb to
continue to the next tcg opcode.  Which then sets all of the static state that
has been assumed (often, as here, just the pc).  We then exit, telling the
cpu_loop to examine cpu state, locate the next TB, and fill in link N from the
current TB.

The second time we cross link N, the link is set, which causes the goto_tb to
continue immediately to the next TB.  We do not execute the store to PC, as it
is implied by next_tb->pc.


r~


  reply	other threads:[~2020-08-30 23:09 UTC|newest]

Thread overview: 122+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18 15:50 [RFC PATCH v3 00/34] Hexagon patch series Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 01/34] Hexagon Update MAINTAINERS file Taylor Simpson
2020-08-26  1:55   ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 02/34] Hexagon (target/hexagon) README Taylor Simpson
2020-08-26  2:06   ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 03/34] Hexagon (include/elf.h) ELF machine definition Taylor Simpson
2020-08-26  2:06   ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 04/34] Hexagon (target/hexagon) scalar core definition Taylor Simpson
2020-08-26 13:35   ` Richard Henderson
2020-08-26 23:51     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 05/34] Hexagon (target/hexagon) register names Taylor Simpson
2020-08-26 13:39   ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 06/34] Hexagon (disas) disassembler Taylor Simpson
2020-08-26 13:52   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 07/34] Hexagon (target/hexagon) scalar core helpers Taylor Simpson
2020-08-26 14:16   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 08/34] Hexagon (target/hexagon) GDB Stub Taylor Simpson
2020-08-26 14:17   ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 09/34] Hexagon (target/hexagon) architecture types Taylor Simpson
2020-08-26 14:19   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 10/34] Hexagon (target/hexagon) instruction and packet types Taylor Simpson
2020-08-26 14:22   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 11/34] Hexagon (target/hexagon) register fields Taylor Simpson
2020-08-26 14:29   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 12/34] Hexagon (target/hexagon) instruction attributes Taylor Simpson
2020-08-26 14:34   ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 13/34] Hexagon (target/hexagon) register map Taylor Simpson
2020-08-26 14:36   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 14/34] Hexagon (target/hexagon) instruction/packet decode Taylor Simpson
2020-08-26 15:06   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 15/34] Hexagon (target/hexagon) instruction printing Taylor Simpson
2020-08-26 15:08   ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 16/34] Hexagon (target/hexagon) utility functions Taylor Simpson
2020-08-26 15:10   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 17/34] Hexagon (target/hexagon/imported) arch import - macro definitions Taylor Simpson
2020-08-26 15:17   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 18/34] Hexagon (target/hexagon/imported) arch import - instruction semantics Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 19/34] Hexagon (target/hexagon/imported) arch import - instruction encoding Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 20/34] Hexagon (target/hexagon) generator phase 1 - C preprocessor for semantics Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 21/34] Hexagon (target/hexagon) generator phase 2 - generate header files Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 22/34] Hexagon (target/hexagon) generator phase 3 - C preprocessor for decode tree Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 23/34] Hexagon (target/hexagon) generater phase 4 - " Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 24/34] Hexagon (target/hexagon) opcode data structures Taylor Simpson
2020-08-26 15:25   ` Richard Henderson
2020-08-26 23:52     ` Taylor Simpson
2020-08-27  4:05       ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 25/34] Hexagon (target/hexagon) macros to interface with the generator Taylor Simpson
2020-08-29  0:49   ` Richard Henderson
2020-08-30 20:30     ` Taylor Simpson
2020-08-30 20:59       ` Richard Henderson
2020-08-30 21:20         ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 26/34] Hexagon (target/hexagon) macros referenced in instruction semantics Taylor Simpson
2020-08-29  1:16   ` Richard Henderson
2020-08-30 20:23     ` Taylor Simpson
2020-08-30 21:06       ` Richard Henderson
2020-10-08 15:00     ` Taylor Simpson
2020-10-08 17:30       ` Richard Henderson
2020-10-08 18:51         ` Taylor Simpson
2020-10-08 20:02           ` Richard Henderson
2020-10-08 20:54             ` Taylor Simpson
2020-10-09 12:59               ` Richard Henderson
2020-10-09 16:02                 ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 27/34] Hexagon (target/hexagon) instruction classes Taylor Simpson
2020-08-29  1:37   ` Richard Henderson
2020-08-30 20:04     ` Taylor Simpson
2020-08-30 20:43       ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 28/34] Hexagon (target/hexagon) TCG generation helpers Taylor Simpson
2020-08-29  1:48   ` Richard Henderson
2020-08-30 19:53     ` Taylor Simpson
2020-08-30 20:52       ` Richard Henderson
2020-08-30 21:38         ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 29/34] Hexagon (target/hexagon) TCG generation Taylor Simpson
2020-08-29  1:58   ` Richard Henderson
2020-08-30 19:49     ` Taylor Simpson
2020-08-18 15:50 ` [RFC PATCH v3 30/34] Hexagon (target/hexagon) TCG for instructions with multiple definitions Taylor Simpson
2020-08-29  2:02   ` Richard Henderson
2020-08-30 19:48     ` Taylor Simpson
2020-08-30 21:13       ` Richard Henderson
2020-08-30 21:30         ` Taylor Simpson
2020-08-30 23:26           ` Richard Henderson
2020-08-31 17:08             ` Taylor Simpson
2020-08-31 17:29               ` Richard Henderson
2020-08-31 18:14                 ` Taylor Simpson
2020-08-31 19:20                   ` Richard Henderson
2020-08-31 23:10                     ` Taylor Simpson
2020-09-01  2:40                       ` Richard Henderson
2020-09-01  4:17                         ` Taylor Simpson
2020-09-24  2:56                           ` Taylor Simpson
2020-09-24 15:03                             ` Richard Henderson
2020-09-24 17:18                               ` Taylor Simpson
2020-09-24 19:04                                 ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 31/34] Hexagon (target/hexagon) translation Taylor Simpson
2020-08-29  2:49   ` Richard Henderson
2020-08-30 19:37     ` Taylor Simpson
2020-08-30 23:08       ` Richard Henderson [this message]
2020-08-18 15:50 ` [RFC PATCH v3 32/34] Hexagon (linux-user/hexagon) Linux user emulation Taylor Simpson
2020-08-29  2:59   ` Richard Henderson
2020-08-18 15:50 ` [RFC PATCH v3 33/34] Hexagon (tests/tcg/hexagon) TCG tests Taylor Simpson
2020-08-29  3:05   ` Richard Henderson
2020-09-01  9:57     ` Alessandro Di Federico
2020-08-18 15:50 ` [RFC PATCH v3 34/34] Hexagon build infrastructure Taylor Simpson
2020-08-29  3:19   ` Richard Henderson
2020-09-24  2:35     ` Taylor Simpson
2020-09-25 16:59       ` Philippe Mathieu-Daudé
2020-08-18 16:32 ` [RFC PATCH v3 00/34] Hexagon patch series no-reply
2020-08-29  3:27 ` Richard Henderson
2020-08-30 20:47   ` Taylor Simpson
2020-08-30 23:33     ` Richard Henderson
2020-08-31 17:57       ` Taylor Simpson
2020-08-31 20:43         ` Richard Henderson
2020-08-31 23:48           ` Taylor Simpson
2020-09-07  9:49     ` Rob Landley
2020-09-15  0:41       ` [EXT] " Brian Cain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a8f99274-a865-0ffb-d49b-648e8be8170c@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=ale@rev.ng \
    --cc=aleksandar.m.mail@gmail.com \
    --cc=laurent@vivier.eu \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    --cc=tsimpson@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).