Re: port-xen/53267 (XEN amd64 DomU (Dom0??) NetBSD current USERMODE() fails)

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

The following reply was made to PR port-xen/53267; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: "Cherry G.Mathew" <cherry%zyx.in@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: port-xen/53267 (XEN amd64 DomU (Dom0??) NetBSD current USERMODE() fails)
Date: Fri, 11 May 2018 17:38:09 +0700

     Date:        Fri, 11 May 2018 14:37:12 +0530
     From:        "Cherry G.Mathew" <cherry%zyx.in@localhost>
     Message-ID:  <87o9hm7e7z.fsf%zyx.in@localhost>
 
   | This was a pretty intrusive change ( we switched to the x86 common
   | interrupt code ), so I'll need a bit of time to figure it out.
 
 Yes, I saw ... and also explains the problem, as regular x86 run the
 kernel and users at different priv levels, but xen does not.   The old
 way, some magic must have been being done to make it appear as if
 there were different levels, which is no longer happening.
 
 I have no idea how all of this works (I don't know x86 architecture at
 all) so I cannot really help with a soltution (I admit to making one wild
 guess, and trying it out - that kernel did not make it through autoconf
 before hanging ... fortunately DomU's are easy to destroy, and bogus
 code is easy to throw away!)
 
 One suggestion though - there is no need for the XEN USERMODE()
 macro to work anything like the x86 one does - it does not need to
 inspect bits in %cs (whatever that is).   Other ports do not.   Any method
 that tells what the mode was before the current interrupt/trap will work.
 
 kre