topic Re: Regarding PVR register access from user space. in P-Series

Regarding PVR register access from user space.

Simbu — Tue, 23 Oct 2012 20:35:30 GMT

Hi All,

I'm facing one bottleneck in using the mfpvr instruction on e500mc hardware (user space). This instruction/register execution/access is supervisor privilage, so register

access from user space should lead to illegal instruction.

We I tried to access this PVR register from user space, the app is able to get the PVR value without extra provisioning.When I checked more from

Kernel perspective identified one procedure (eumulate_instructio) in traps.c which is emulating the program exceptions

irrespective of user/kernel mode.

I have following queries:

--> Is this kind of emulation is configurable one?? ( I don't see any compile time MACRO for PVR register).

--> Any idea why there is no check placed to make sure the process (user level) has signal handler defined for illegal instructions which is about to emulate?

--> How can remove such dependencies from Kernel ( I don't want the Kernel to perform any extra job like emulation)

Thanks in Advance.

Re: Regarding PVR register access from user space.

scottwood — Wed, 24 Oct 2012 01:22:51 GMT

This particular emulation is not configurable. It exists for legacy reasons.

What sort of check are you talking about? Why would the decision to emulate PVR be based on whether the user has a SIGILL handler?

If you want the kernel to not emulate this, you can change the code in emulate_instruction() in arch/powerpc/kernel/traps.c. Trying to eliminate all "extra jobs" from Linux might be an exercise in futility, though. Why is your userspace accessing PVR? What is the harm in the emulation?

Re: Regarding PVR register access from user space.

Simbu — Wed, 24 Oct 2012 06:41:13 GMT

Thanks for quick reply Scott !

We have a user space application to emulate all the illegal instructions from our end (user space) by creating a virtual environment. We have noticed that this instruction or register

access is no more illegal in new kernel (2.6.34.10).

The problem with this behavior is a system which is under emulation still things that it is running on old hardware by referring to this PVR register,

but now the behavior is changed because our emulation app is able to retrieve the current running CPU PVR (not matching with virtual one) and not referring the virtual register.

Also, I can see these changes was not present in Linux 2.6.10 (PPC64) and added later on by patch..True??

What sort of check are you talking about? Why would the decision to emulate PVR be based on whether the user has a SIGILL handler?

[S] Like, mentioned above if we have our own emulation path why Kernel is taking extra effort to perform the same.In the other way around, if the interrupted process (process executed the illegal instruction) has the facility to handle

illegal instruction action then it impacts the user level virtual environment ?? (I'm not sure whether same applicable for KVM??)

[S] Yea.. We're in the progress of making these code changes, but thought some generic check (which will help open source too) to avoid the above situation.

Why is your userspace accessing PVR?

[S] Operating system which we are emulating from user space level is accessing the PVR and expectation here is to invoke the illegal handler bound for this action.

What is the harm in the emulation?

[S] Because of this emulation (@Kernel level), the user level process is able to get a new PVR instead of Virtual/hardocoded value which has broken the illusion between the operating system and emulator/hardware.

Re: Regarding PVR register access from user space.

scottwood — Thu, 29 Oct 2020 08:50:23 GMT

Simbu wrote:

Thanks for quick reply Scott !

We have a user space application to emulate all the illegal instructions from our end (user space) by creating a virtual environment. We have noticed that this instruction or register

access is no more illegal in new kernel (2.6.34.10).

The problem with this behavior is a system which is under emulation still things that it is running on old hardware by referring to this PVR register,

but now the behavior is changed because our emulation app is able to retrieve the current running CPU PVR (not matching with virtual one) and not referring the virtual register.

Also, I can see these changes was not present in Linux 2.6.10 (PPC64) and added later on by patch..True??

PVR has been emulated by the Linux kernel since the beginning of arch/powerpc (see emulate_instruction() in commit 14cf11af6cf608eb8c23e989ddb17a715ddce109). It was present in arch/ppc and arch/ppc64 as of the first git commit (1da177e4c3f41524e886b7f1b8a0c1fc7321cac2) which represented v2.6.12-rc2. I don't know when prior to that it was added, but it's been around a long time.

What sort of check are you talking about? Why would the decision to emulate PVR be based on whether the user has a SIGILL handler?

[S] Like, mentioned above if we have our own emulation path why Kernel is taking extra effort to perform the same.In the other way around, if the interrupted process (process executed the illegal instruction) has the facility to handle

illegal instruction action then it impacts the user level virtual environment ?? (I'm not sure whether same applicable for KVM??)

Having a SIGILL handler registered does not mean you want to emulate everything yourself. There are lots of reasons for registering such a handler -- you may just want the ability to do some cleanup and error logging before the process dies.

KVM has its own exception handling and is not affected by this (though we do not support PVR different from host in KVM on embedded PPC -- we can't even trap on it when using HV extensions).

Running kernel code in an ordinary user process is not supported, regardless of what signal handlers you have installed. If you can make it work to your satisfaction, great, but expect difficulty. If you really need to do this, and need the code to see a different PVR, I suggest using QEMU to emulate the CPU in question.