RE: [Linux-ia64] determining read or write on a page fault

[David Mosberger <davidm@hpl.hp.com>]

>>>>> On Fri, 22 Feb 2002 07:58:31 -0800, "Hoeflinger, Jay P" <jay.p.hoeflinger@intel.com> said:

  Jay> Decoding the instruction seems really messy, but maybe I am not
  Jay> familiar enough with the Itanium architecture.

It shouldn't be that bad.  For a DSM, you only need to be able to
reliably detect stores (everything else you can just assume to be
loads).

  Jay> Apparently the
  Jay> PC points to an instruction bundle and memory instructions can
  Jay> appear in both slots 0 and 1, meaning you have to do more than
  Jay> just determining whether a single instruction was a load or a
  Jay> store.

Bits 0 and 1 in the IP stored in the sigcontext (sc_ip) encode the
slot number 0, so you'll know exactly which instruction caused the
fault.

  Jay> What if one slot has a load and the other a store?  In that
  Jay> case you have to resort to matching the address with the
  Jay> address computed in the instruction, which can be in a
  Jay> register, but I don't know how to determine whether the current
  Jay> register contents are valid, or whether I have to find the
  Jay> register save area where the value was saved at the time of the
  Jay> fault.  Additionally, there could be an immediate value that is
  Jay> added to the register contents, so the decoder code must
  Jay> compute the same address that the instruction computed before
  Jay> it can compare that to the address passed in sigcontext.

None of that should be necessary.

  Jay> All of this sounds do-able, but it will take time to make sure
  Jay> the code mimics the address computation precisely.

  Jay> What isn't do-able is to handle currently undefined op-codes.
  Jay> This means that when new instructions are added, existing
  Jay> binaries break and we have to revise the decoder.

  Jay> In looking at the kernel page-fault code, we see that the
  Jay> memory access type is known at the time of signal dispatch, but
  Jay> then not passed through to the user's signal handler.  Couldn't
  Jay> the kernel just pass the access type in sigcontext (this is how
  Jay> it was done in IA32)?  In the event that the access type is not
  Jay> appropriate, then the access type could be tagged UNKNOWN.

Yes, we can do that and I'm planning to make such a change.  The solution
Hans proposed is what you'd have to do if you need things working with
today's kernels.

If you're willing to wait for a new kernel, I can send you a patch
that adds the extra info to siginfo.

  Jay> It seems that this change to the page-fault code would be
  Jay> practically free since the information is already available,
  Jay> and it would save us (and others) from writing a difficult
  Jay> instruction-decoder that will break as soon as a new
  Jay> instruction is added to IPF.

Yes, clearly that's preferable in the longer term.  Nobody is
objecting to doing this, it's just that nobody has gotten around to
implementing it so far.

	--david