[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Detecting Faulting Instructions From Plugins

From: Alex Bennée
Subject: Re: Detecting Faulting Instructions From Plugins
Date: Mon, 01 Feb 2021 12:07:13 +0000
User-agent: mu4e 1.5.7; emacs 28.0.50

Aaron Lindsay <aaron@os.amperecomputing.com> writes:

> On Jan 29 22:23, Aaron Lindsay wrote:
>> 1. Is this considered a bug or a "feature"?
>> 2.a. If a bug, is there a good way to detect this from inside the
>>       tcg/plugin infrastructure and avoid calling the callback for the
>>       faulting execution of the instruction?
>> 2.b. If a "feature", is there a good way to detect this from my plugin?
> I think I've convinced myself the current behavior *is* a "feature", and
> working as intended since the instruction can be considered
> architecturally committed, even if it faults (ARM statement).

Yes I think that's correct. I assume in between the page-fault handler
has run and ensured the page is properly mapped and then returned to
*re*-execute the instruction.

> But I am
> still unsure of the best way to detect whether a load/store instruction
> has faulted from within the plugin interface, so I welcome thoughts
> there.

A hacky method would be to:

  a) track last executed PC on a per-vCPU basis in the callbacks for
  b) have a specific callback handler for the head of the vector table
  for synchronous exceptions.

It wouldn't be ideal because you need some knowledge of where the table
is and depending on the architecture the entry may be shared between
synchronous (i.e. the last instruction that attempted to execute) and
asynchronous ones (e.g. a timer just happened to fire).

If we get to the point we can expose the register values to the plugin
then it becomes a much simpler operation because there will be state
information exposed somewhere in the register state.

> -Aaron

Alex Bennée

reply via email to

[Prev in Thread] Current Thread [Next in Thread]