Re: Is there a current known getrusage() problem (amd64)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 4 Apr 2018 17:05:51 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <201804042105.RAA04131%Stone.Rodents-Montreal.ORG@localhost>

  | >> Hmm...have you tried [various suggestions]?
  | > No, to all of those - and all good suggestions (and since this is a
  | > XEN DomU I can give it just 1 CPU as well...)
  |
  | Might also be interesting to see whether/how the symptoms change on
  | real hardware, if you have any such available; with xen in the mix
  | there are a bunch more possible places bugs could be causing trouble.

I suspect they probably will, and yes, I could test this there (been meaning
to update my laptop kernel anyway...)   but I am now not sure I will need to
do that, as some progress has been made (almost by fluke).

  | see that name: what, you're trying to configure Chris Demetriou?)
:-)


What I saw that "revealed all" is from sysctl ...

kern.cp_time: user = 0, nice = 0, sys = 6764, intr = 107, idle = 4968970

The test system has been up, idling, for about 14 hours, so that idle
time is right.   The intr time (about 1 second) seems reasonable.

But all the time being counted as system time, and none user time, is
what I was seeing from the time command as well.

What this means to me is that the test in kern_clock.c

        if (CLKF_USERMODE(frame)) {

is failing, and most likely just on XEN, as we know that the user/kernel
distinction is done differently there than is on real hardware.

On amd64, CLKF_USERMODE is just

#define     CLKF_USERMODE(frame)    USERMODE((frame)->cf_if.if_tf.tf_cs)

and

#define USERMODE(c)            (ISPL(c) == SEL_UPL)

These seem to apply unchanged for XEN - whether that is appropriate or
not I have no idea.

This is about where I hit a brick wall, as now we're into details of x86 
hardware, and how it is modified for XEN.

But if I had to guess where this problem might have originated, I'm going
to suspect arch/amd64/include/segments.h rev 1.34

"Fix a huge privilege separation vulnerability in Xen-amd64."

I am going to (locally) revert that and see if the problem goes away.
If it does, then I will leave it for maxv to make appropriate changes
to USERMODE() for XEN so it works correctly.

kre