Hi Gabe,
Thanks for the reply. Actually I have managed to decode the problem before the
last weekend. Yes, it is actually not due to “finding the sys/mman.h” but
something very unrelated (“CC” variable wrong).
It seems the configure made two tries for the conf_13 and conf_14 . First time
Hi Bruce:
I see the GEM5 resource mentioned on the GEM5 official website. Are
all the resources provided in the GEM5 resource based on x86? For example,
SPEC2017, are there AARCH64-based versions available for these resources?
Best regards,
Liyichao
发件人: Bobby Bruce via gem5-users
Adding “EventQueue::ScopedMigration migrate(eventQueue());” in kick() function
in class VirtIODeviceBase does work now, thanks.
class VirtIODeviceBase : public SimObject
{
public:
typedef uint16_t QueueID;
typedef uint32_t FeatureBits;
/** This is a VirtQueue address as exposed
I look into the code, and find that the kick() function in
VirtIO9PBase::sendRMsg function in fs9p.cc is defined in class VirtIODeviceBase:
class VirtIODeviceBase : public SimObject
{
public:
typedef uint16_t QueueID;
typedef uint32_t FeatureBits;
/** This is a VirtQueue address as
Hi Gabe:
You mean that the code to be modified just like this?
void
PciVirtIO::kick()
{
DPRINTF(VIOIface, "kick(): Sending interrupt...\n");
EventQueue::ScopedMigration migrate(eventQueue());
interruptDeliveryPending = true;
intrPost();
}
void