Re: [Gems-users] UserMode vs. SupervisorMode cache requests

[Byn Choi <bynchoi1@xxxxxxxxxxxx>]

Carole,

Judging by the fact that you're looking at mem_op->mode, I'm assuming you're doing x86 simulation. mem_op, which of type x86_memory_transaction_t is a simics object, for which you can find the documentation in the simics reference manual.

AccessModeType.h defines the access mode type used internally in ruby. The translation occurs somewhere in SimicsProcessor::makeRequest().

Coming back to mem_op->mode, it looks like it is of type processor_mode_t, which is

typedef enum {

   SIM_CPU_Mode_User = 0,

   SIM_CPU_Mode_Supervisor = 1,

   SIM_CPU_Mode_Hypervisor

} processor_mode_t;

It is indeed weird that simics is returning values other than 0, 1, or 2. However, I think judging by the strict definition above, it's safe to say that any mem_op that doesn't have its mode field set to 0 for sure isn't usermode access.

Byn

On Feb 18, 2010, at 2:23 PM, Carole-Jean Wu wrote:

Hello,

Thanks for all of your response.

The codes that handles the user/supervisor mode checks are returning strange values. I inserted my own debugging codes in ruby_operate(xxx) of ruby/modules/ruby.c to print out mem_op->mode. This variable, defined as enum in ruby/generated/MSI_MOSI_CMP_directory/AccessModeType.h should return something between 0 and 3; however, it returns very arbitrary values, e.g. 32771, 32779, etc etc.

Can you suggest possible fixes for this problem?

Thanks very much,
Carole

On Thu, Feb 18, 2010 at 1:35 AM, Philip Garcia <pcgarcia@xxxxxxxx> wrote:

I'm pretty sure there's a bug in Opal regarding the change in context, and in the default install, it doesn't change what context is running.  If this is the case, it's possible that the code that handles the user/supervisor mode checks might be checking the context and testing for zero, and always returning the wrong value.

Phil

On Feb 17, 2010, at 10:31 PM, Byn Choi wrote:

> Carole,
>
> With stock install (no manual changes to ruby/opal), you should see usermode accesses, as long as the setup is correct, i.e. there actually is a usermode app running inside the simulation environment. You may want to double check that first.
>
> If you are sure that there is an app running inside your simulation environment, then the next place to poke around is the simics-ruby interface, specifically the ruby_operate function in ruby/module/ruby.c. This gets called every time simics wants to do a memory access, and it passes an object of type generic_transaction_t to ruby. Follow from there how the request passed down through ruby/simics/Commands.C, ruby/simics/SimicsDriver.C and eventually ruby/simics/SimicsProcessor.C. There, it gets converted to CacheMsg type.
>
> I would first do a sanity check by putting a small code along that call chain to see if I am actually getting any usermode accesses through that ruby interface - small code to keep a count of such accesses, run for a while, check to see if it's non-zero. If it isn't, then at least you know your checkpoint isn't the problem, and you can go from there.
>
> Byn
>
> On Feb 17, 2010, at 10:10 PM, Carole-Jean Wu wrote:
>
>> Hello list,
>>
>> I would like to separate user mode requests from supervisor mode requests in Simics-3.0.x/GEMS-2.1.X. I know that there is a field in all cache messages, called AccessModeType, which is set to either UserMode of SupervisorMode. However, in my ruby statistic files, I do not see any UserMode requests at all. Did any of you experience similar situation? Or, can someone point me where to look at?
>>
>> Thanks in advance,
>> Carole
>> _______________________________________________
>> Gems-users mailing list
>> Gems-users@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.