How does the ruby_hitcallback work in Rocks?

ruby_hitcall is the primary method that Ruby communicates with the Bochs system. When Bochs issues a memory request to Ruby, it set up the ruby_hitcallback through the libruby_get_port in $ROCKS/bochs/cpu/init.cc
/**

*  Retrieve a handle to a RubyPort object, identified by name in the
*  configuration.  You also pass in the callback function you want
*  this port to use when a request completes.  Only one handle to a
*  port is allowed at a time.
*/

RubyPortHandle libruby_get_port(const char* name, void (*hit_callback)(int64_t access_id));
This RubyPortHandle is part of the CPU object in bochs. It is defined in $ROCKS/bochs/cpu/cpu.h:793.
When libruby_issue_request is called, the Ruby_PortHandle is passed alone with the RubyRequest Struct. 
The Ruby_PortHandle is defined in
gem5/src/mem/ruby/libruby.hh:8
typedef void* RubyPortHandle;

This pointer is set up in the configuration time through the rocks script. The RubySystem is defined in the $ROCKS/gem5/src/mem/ruby/System.hh and it is just a big container that has everything.

Ruby_PortHandle is casted into RubyPort in libruby_issue_request at libruby.cc.

RubyPort class is in system/RubyPort.hh and other classes inherit from this class. Important ones are Sequencer class and DMASequencer class.

And in RubyPort class, one could make a request. This request can be then a memory request.

Who calls this Ruby_hitcallback? Ruby or Bochs? What is Bochs role? What is Ruby's Role?

In essence, the bochs register a call back for Ruby to call when ruby is done. And Ruby side port, such as sequencer will call the callback function when it is done. The point of the callback is stored in Sequencer, which is child class of RubyPort. 

This is a short description that I wrote on the wiki:
ruby_hitcall, defined in $ROCKS/bx_ruby_interface/bx_ruby_memory.cc is the primary method that Ruby communicates with the Bochs system. When Bochs initiates at the beginning of everything, Bochs sets up ports in the M5 fashion to communicate with Ruby. These ports will allow Bochs to issues memory request to Ruby. When the port was set up through the libruby_get_port in $ROCKS/bochs/cpu/init.cc, a function pointer is passed to the RubyPort object, stored as m_hit_callback. The definition of the RubyPort object can be found at $ROCKS/gem5/src/mem/ruby/system/RubyPort.hh/cc. The primary object in Ruby that receives the memory requests are the Sequencer object and the DMASequencer object. They are both defined in the $ROCKS/gem5/src/mem/ruby/system and both inherits from the RubyPort class. In the member function Sequencer::hitCallback, the function pointer is used by the Sequencer to call Bochs. This function pointer in Sequencer will call ruby_hitcallback.The implementation for DMASequencer is in a similar fashion.