[gem5-users] Re: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Gabe Black via gem5-users]

Please take the version that works for you and create a review:

http://www.gem5.org/contributing

It's much easier to look at changes in the code review interface, and we
can add reviewers who are most familiar with this code.

Gabe

On Tue, Mar 16, 2021 at 2:59 AM Liyichao  wrote:

> 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 through the low-level
>
>  * interface.\ The address needs to be multiplied by the page size
>
>  * (seems to be hardcoded to 4096 in the spec) to get the real
>
>  * physical address.
>
>  */
>
> typedef uint16_t VirtAddress;
>
> /** Device Type (sometimes known as subsystem ID) */
>
> typedef uint16_t DeviceId;
>
>
>
> BitUnion8(DeviceStatus)
>
> Bitfield<7> failed;
>
> Bitfield<2> driver_ok;
>
> Bitfield<1> driver;
>
> Bitfield<0> acknowledge;
>
> EndBitUnion(DeviceStatus)
>
>
>
> typedef VirtIODeviceBaseParams Params;
>
> VirtIODeviceBase(Params *params, DeviceId id, size_t config_size,
>
>  FeatureBits features);
>
> virtual ~VirtIODeviceBase();
>
>
>
>   public:
>
> /** @{
>
>  * @name SimObject Interfaces
>
>  */
>
> void serialize(CheckpointOut ) const override;
>
> void unserialize(CheckpointIn ) override;
>
> /** @} */
>
>
>
>   protected:
>
> /** @{
>
>  * @name Device Model Interfaces
>
>  */
>
>
>
> /**
>
>  * Inform the guest of available buffers.
>
>  *
>
>  * When a device model has finished processing incoming buffers
>
>  * (after onNotify has been called), it typically needs to inform
>
>  * the guest that there are new pending outgoing buffers. The
>
>  * method used to inform the guest is transport dependent, but is
>
>  * typically through an interrupt. Device models call this method
>
>  * to tell the transport interface to notify the guest.
>
>  */
>
> void kick() {
>
> assert(transKick);
>
>EventQueue::ScopedMigration migrate(eventQueue());
>
> transKick->process();
>
> };
>
>
>
>
>
>
>
> *发件人:* Liyichao
> *发送时间:* 2021年3月16日 14:06
> *收件人:* 'Gabe Black' 
> *抄送:* gem5 users mailing list 
> *主题:* 答复: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
>
>
>
> 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 exposed through the low-level
>
>  * interface.\ The address needs to be multiplied by the page size
>
>  * (seems to be hardcoded to 4096 in the spec) to get the real
>
>  * physical address.
>
>  */
>
> typedef uint16_t VirtAddress;
>
> /** Device Type (sometimes known as subsystem ID) */
>
> typedef uint16_t DeviceId;
>
>
>
> BitUnion8(DeviceStatus)
>
> Bitfield<7> failed;
>
> Bitfield<2> driver_ok;
>
> Bitfield<1> driver;
>
> Bitfield<0> acknowledge;
>
> EndBitUnion(DeviceStatus)
>
>
>
> typedef VirtIODeviceBaseParams Params;
>
> VirtIODeviceBase(Params *params, DeviceId id, size_t config_size,
>
>  FeatureBits features);
>
> virtual ~VirtIODeviceBase();
>
>
>
>   public:
>
> /** @{
>
>  * @name SimObject Interfaces
>
>  */
>
> void serialize(CheckpointOut ) const override;
>
> void unserialize(CheckpointIn ) override;
>
> /** @} */
>
>
>
>   protected:
>
> /** @{
>
>  * @name Device Model Interfaces
>
>  */
>
>
>
> /**
>
>  * Inform the guest of available buffers.
>
>  *
>
>  * When a device model has finished processing incoming buffers
>
>  * (after onNotify has been called), it typically needs to inform
>
>  * the guest that there are new pending outgoing buffers. The
>
>  * method used to inform the guest is transport dependent, but is
>
>  * typically through an interrupt. Device models call this method
>
>  * to tell the transport interface to notify the guest.
>
>  */
>
> void kick() {
>
> assert(transKick);
>
>EventQueue::ScopedMigration migrate(eventQueue());
>
> transKick->process();
>
> };
>
>
>
> But not define in MmioVirtIO and PciVirtIO as you mentioned.
>
>
>
> So should I declared in the kick() definition?
>
>
>
> void kick() {
>
>EventQueue::ScopedMigration migrate(eventQueue());
>
> assert(transKick);
>
> transKick->process();
>
> };
>
>
>
>
>
> *发件人:* Gabe Black 

[gem5-users] Re: Custom M5Ops

[Gabe Black via gem5-users]

Hi Sam, there are a few ways you can do that.

1. You could set up a PC based event if you know what PC your behavior will
always be triggered from (see examples like skipping udelay for some
versions of the linux kernel).
2. You could create a new gem5 op by picking an unused number and a wrapper
stub in the header files I think you've found. Then in gem5 itself, you'd
add an implementation in src/sim/pseudo_inst.(hh|cc). The fairly trivial
"sum" gem5 op is probably a good example.
3. You could use the existing m5_workload gem5 op which basically just
pokes the workload object and tells it something interesting is happening.
The workload can then inspect state and look at registers, the PC, etc to
figure out what you want to happen. You can think of this sort of like a
system call but into the simulator. You'd need to create your own workload
class (which could be/would likely be based on an existing one) to
implement this back end logic. This is how I intend the system calls in SE
mode to be implemented one of these days.

Gabe

On Tue, Mar 16, 2021 at 4:55 AM Samuel Thomas via gem5-users <
gem5-users@gem5.org> wrote:

> Hello,
>
> I’m working on a project where I want to trigger a hardware procedure from
> software. I can see in the gem5/include/gem5/asm/generic/m5ops.h file,
> there is a certain amount of address space allocated for user customizable
> operations like this. Is there documentation as to how to use this address
> space and make a custom operation?
>
> Thank you for your help!
>
> Best,
> Sam
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Dump_and_reset_stats in various cpu types

[Michail Mavropoulos via gem5-users]

Hi all,

I have a question regarding m5_dump_reset_stats instruction and 
different cpu-types.


I have included the m5_dump_reset_stats instruction into a code and as 
it is expected the stats file splits into two sections.
When I setup the cpu-type equal to TimingSimpleCPU, I observe that the 
L1 stats are not reset. For example, the dl1 misses reported on the 
second stats section are equal to the dl1 misses reported when I don't 
make use of the m5 instruction. This does not happen for L2 statistics, 
so in l2 case in order to match the l2 misses reported when m5 
instruction not in use I have to add the l2 misses reported in two stats 
sections.

This issue does not occurs when DeriveO3CPU cpu type is selected.

Is it a known issue? Why when I run a timing simulation the stats of L1 
caches do not reset?


I am using a gem5 version with head commit id: 
9d3b9e96c56386ee6539657c21cba95e118e576a, Octomber 15th, 2019.


Best regards,
Michail
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Running ARM FS mode

[Giacomo Travaglini via gem5-users]

Hi,

You are not providing a --disk-image option to fs.py

You should download the latest AArch32 disk image from the link you mentioned 
and pass it to the command line:

https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries

Kind Regards

Giacomo

> -Original Message-
> From: Đức Anh via gem5-users 
> Sent: 16 March 2021 15:44
> To: gem5 users mailing list 
> Cc: Đức Anh 
> Subject: [gem5-users] Running ARM FS mode
>
> Dear all,
>
> I am trying to run the Gem5 simulation in FS mode and ARM architecture with
> the resource provided from the repo. However, I am running into this error
>
>
> No filesystem could mount root, tried:
>  ext3
>   ext4
>   ext2
>  squashfs
>   vfat
>   fuseblk
>
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(1,0)
>
>
> The error occurred in both stable and develop branch. The command I use it:
>
>
> ./build/ARM/gem5.opt configs/example/fs.py
> --kernel=configs/thesis/arm/binaries/vmlinux.arm
> --machine-type=VExpress_GEM5_V1
> --dtb-file=system/arm/dt/armv7_gem5_v1_1cpu.dtb
> --bootloader=system/arm/bootloader/arm/boot.arm
> --command-line 'earlyprintk=pl011,0x1c09 lpj=19988480 rw
> loglevel=8 mem=256MB root=/dev/ram0 console_msg_format=syslog
> nokaslr norandmaps panic=-1 printk.devkmsg=on printk.time=y rw
> console=ttyAMA0 - lkmc_home=/lkmc'
>
>
> The kernel and bootloader I got from the guest binaries page
>  naries> , latest Linux Kernel Image / Bootloader (recommended). DTB file is
> generated by the command make -C system/arm/dt.
>
>
> Before I used this command line instead
>
> ./build/ARM/gem5.opt configs/example/fs.py
> --kernel=configs/thesis/arm/binaries/vmlinux.arm
> --machine-type=VExpress_GEM5_V1
> --dtb-file=system/arm/dt/armv7_gem5_v1_1cpu.dtb
> --bootloader=system/arm/bootloader/arm/boot.arm
>
>
> The same as the above except for the command-line arg. I got the following
> error
>
>
> VFS: Cannot open root device "sda1" or unknown-block(0,0): error -6
> [0.764532] Please append a correct "root=" boot option; here are
> the available partitions:
> [0.764537] 01004096 ram0
> [0.764538]  (driver?)
> [0.764545] 01014096 ram1
> [0.764546]  (driver?)
> [0.764552] 01024096 ram2
> [0.764553]  (driver?)
> [0.764560] 01034096 ram3
> [0.764561]  (driver?)
> [0.764567] 01044096 ram4
> [0.764569]  (driver?)
> [0.764575] 01054096 ram5
> [0.764576]  (driver?)
> [0.764583] 01064096 ram6
> [0.764584]  (driver?)
> [0.764590] 01074096 ram7
> [0.764591]  (driver?)
> [0.764598] 01084096 ram8
> [0.764599]  (driver?)
> [0.764605] 01094096 ram9
> [0.764606]  (driver?)
> [0.764613] 010a4096 ram10
> [0.764614]  (driver?)
> [0.764620] 010b4096 ram11
> [0.764622]  (driver?)
> [0.764628] 010c4096 ram12
> [0.764629]  (driver?)
> [0.764636] 010d4096 ram13
> [0.764637]  (driver?)
> [0.764643] 010e4096 ram14
> [0.764644]  (driver?)
> [0.764651] 010f4096 ram15
> [0.764652]  (driver?)
> [0.764662] Kernel panic - not syncing: VFS: Unable to mount root fs
> on unknown-block(0,0)
>
>
> That why I add the command-line option and specify ram0 as the root, but
> the simulation is still not working.
>
> Can anyone help me with this?
>
> Thank you,
> Duc Anh
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Running ARM FS mode

[Đức Anh via gem5-users]

Dear all,

I am trying to run the Gem5 simulation in FS mode and ARM architecture with
the resource provided from the repo. However, I am running into this error

No filesystem could mount root, tried:
>  ext3
>   ext4
>   ext2
>  squashfs
>   vfat
>   fuseblk
>
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(1,0)


The error occurred in both stable and develop branch. The command I use it:

./build/ARM/gem5.opt configs/example/fs.py
> --kernel=configs/thesis/arm/binaries/vmlinux.arm
> --machine-type=VExpress_GEM5_V1
> --dtb-file=system/arm/dt/armv7_gem5_v1_1cpu.dtb
> --bootloader=system/arm/bootloader/arm/boot.arm
> --command-line 'earlyprintk=pl011,0x1c09 lpj=19988480 rw
> loglevel=8 mem=256MB *root=/dev/ram0* console_msg_format=syslog nokaslr
> norandmaps panic=-1 printk.devkmsg=on printk.time=y rw console=ttyAMA0 -
> lkmc_home=/lkmc'


The kernel and bootloader I got from the guest binaries page
,
latest Linux Kernel Image / Bootloader (recommended). DTB file is generated
by the command *make -C system/arm/dt.*

Before I used this command line instead

> ./build/ARM/gem5.opt configs/example/fs.py
> --kernel=configs/thesis/arm/binaries/vmlinux.arm
> --machine-type=VExpress_GEM5_V1
> --dtb-file=system/arm/dt/armv7_gem5_v1_1cpu.dtb
> --bootloader=system/arm/bootloader/arm/boot.arm


The same as the above except for the command-line arg. I got the following
error

VFS: Cannot open root device "sda1" or unknown-block(0,0): error -6
> [0.764532] Please append a correct "root=" boot option; here are the
> available partitions:
> [0.764537] 01004096 ram0
> [0.764538]  (driver?)
> [0.764545] 01014096 ram1
> [0.764546]  (driver?)
> [0.764552] 01024096 ram2
> [0.764553]  (driver?)
> [0.764560] 01034096 ram3
> [0.764561]  (driver?)
> [0.764567] 01044096 ram4
> [0.764569]  (driver?)
> [0.764575] 01054096 ram5
> [0.764576]  (driver?)
> [0.764583] 01064096 ram6
> [0.764584]  (driver?)
> [0.764590] 01074096 ram7
> [0.764591]  (driver?)
> [0.764598] 01084096 ram8
> [0.764599]  (driver?)
> [0.764605] 01094096 ram9
> [0.764606]  (driver?)
> [0.764613] 010a4096 ram10
> [0.764614]  (driver?)
> [0.764620] 010b4096 ram11
> [0.764622]  (driver?)
> [0.764628] 010c4096 ram12
> [0.764629]  (driver?)
> [0.764636] 010d4096 ram13
> [0.764637]  (driver?)
> [0.764643] 010e4096 ram14
> [0.764644]  (driver?)
> [0.764651] 010f4096 ram15
> [0.764652]  (driver?)
> [0.764662] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)


That why I add the command-line option and specify ram0 as the root, but
the simulation is still not working.

Can anyone help me with this?

Thank you,
Duc Anh
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Custom M5Ops

[Samuel Thomas via gem5-users]

Hello,

I’m working on a project where I want to trigger a hardware procedure from 
software. I can see in the gem5/include/gem5/asm/generic/m5ops.h file, there is 
a certain amount of address space allocated for user customizable operations 
like this. Is there documentation as to how to use this address space and make 
a custom operation?

Thank you for your help!

Best,
Sam
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Out of order memory responses

[lsteiner--- via gem5-users]

Hello,
the AXI protocol allows the modeling of out of order memory responses for 
requests with different thread IDs. Responses to requests with the same thread 
ID have to be in order.
Is there a similar concept in gem5 timing mode? Does gem5 also support out of 
order responses from the main memory? And is there any documentation about this 
topic?
Thanks for your help!
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] 答复: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Liyichao 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 through the low-level
 * interface.\ The address needs to be multiplied by the page size
 * (seems to be hardcoded to 4096 in the spec) to get the real
 * physical address.
 */
typedef uint16_t VirtAddress;
/** Device Type (sometimes known as subsystem ID) */
typedef uint16_t DeviceId;

BitUnion8(DeviceStatus)
Bitfield<7> failed;
Bitfield<2> driver_ok;
Bitfield<1> driver;
Bitfield<0> acknowledge;
EndBitUnion(DeviceStatus)

typedef VirtIODeviceBaseParams Params;
VirtIODeviceBase(Params *params, DeviceId id, size_t config_size,
 FeatureBits features);
virtual ~VirtIODeviceBase();

  public:
/** @{
 * @name SimObject Interfaces
 */
void serialize(CheckpointOut ) const override;
void unserialize(CheckpointIn ) override;
/** @} */

  protected:
/** @{
 * @name Device Model Interfaces
 */

/**
 * Inform the guest of available buffers.
 *
 * When a device model has finished processing incoming buffers
 * (after onNotify has been called), it typically needs to inform
 * the guest that there are new pending outgoing buffers. The
 * method used to inform the guest is transport dependent, but is
 * typically through an interrupt. Device models call this method
 * to tell the transport interface to notify the guest.
 */
void kick() {
assert(transKick);
   EventQueue::ScopedMigration migrate(eventQueue());
transKick->process();
};



发件人: Liyichao
发送时间: 2021年3月16日 14:06
收件人: 'Gabe Black' 
抄送: gem5 users mailing list 
主题: 答复: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM mode with 
more than 1 core

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 exposed through the low-level
 * interface.\ The address needs to be multiplied by the page size
 * (seems to be hardcoded to 4096 in the spec) to get the real
 * physical address.
 */
typedef uint16_t VirtAddress;
/** Device Type (sometimes known as subsystem ID) */
typedef uint16_t DeviceId;

BitUnion8(DeviceStatus)
Bitfield<7> failed;
Bitfield<2> driver_ok;
Bitfield<1> driver;
Bitfield<0> acknowledge;
EndBitUnion(DeviceStatus)

typedef VirtIODeviceBaseParams Params;
VirtIODeviceBase(Params *params, DeviceId id, size_t config_size,
 FeatureBits features);
virtual ~VirtIODeviceBase();

  public:
/** @{
 * @name SimObject Interfaces
 */
void serialize(CheckpointOut ) const override;
void unserialize(CheckpointIn ) override;
/** @} */

  protected:
/** @{
 * @name Device Model Interfaces
 */

/**
 * Inform the guest of available buffers.
 *
 * When a device model has finished processing incoming buffers
 * (after onNotify has been called), it typically needs to inform
 * the guest that there are new pending outgoing buffers. The
 * method used to inform the guest is transport dependent, but is
 * typically through an interrupt. Device models call this method
 * to tell the transport interface to notify the guest.
 */
void kick() {
assert(transKick);
   EventQueue::ScopedMigration migrate(eventQueue());
transKick->process();
};

But not define in MmioVirtIO and PciVirtIO as you mentioned.

So should I declared in the kick() definition?

void kick() {
   EventQueue::ScopedMigration migrate(eventQueue());
assert(transKick);
transKick->process();
};


发件人: Gabe Black [mailto:gabe.bl...@gmail.com]
发送时间: 2021年3月16日 13:55
收件人: Liyichao mailto:liyic...@huawei.com>>
抄送: gem5 users mailing list mailto:gem5-users@gem5.org>>
主题: Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM mode with 
more than 1 core

Yes exactly, did that help?

Gabe

On Mon, Mar 15, 2021 at 10:29 PM Liyichao 
mailto:liyic...@huawei.com>> wrote:
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
MmioVirtIO::kick()
{
DPRINTF(VIOIface, "kick(): Sending interrupt...\n");
EventQueue::ScopedMigration migrate(eventQueue());
setInterrupts(interruptStatus | INT_USED_RING);
}

[gem5-users] 答复: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Liyichao via gem5-users]

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 exposed through the low-level
 * interface.\ The address needs to be multiplied by the page size
 * (seems to be hardcoded to 4096 in the spec) to get the real
 * physical address.
 */
typedef uint16_t VirtAddress;
/** Device Type (sometimes known as subsystem ID) */
typedef uint16_t DeviceId;

BitUnion8(DeviceStatus)
Bitfield<7> failed;
Bitfield<2> driver_ok;
Bitfield<1> driver;
Bitfield<0> acknowledge;
EndBitUnion(DeviceStatus)

typedef VirtIODeviceBaseParams Params;
VirtIODeviceBase(Params *params, DeviceId id, size_t config_size,
 FeatureBits features);
virtual ~VirtIODeviceBase();

  public:
/** @{
 * @name SimObject Interfaces
 */
void serialize(CheckpointOut ) const override;
void unserialize(CheckpointIn ) override;
/** @} */

  protected:
/** @{
 * @name Device Model Interfaces
 */

/**
 * Inform the guest of available buffers.
 *
 * When a device model has finished processing incoming buffers
 * (after onNotify has been called), it typically needs to inform
 * the guest that there are new pending outgoing buffers. The
 * method used to inform the guest is transport dependent, but is
 * typically through an interrupt. Device models call this method
 * to tell the transport interface to notify the guest.
 */
void kick() {
assert(transKick);
transKick->process();
};

But not define in MmioVirtIO and PciVirtIO as you mentioned.

So should I declared in the kick() definition?

void kick() {
   EventQueue::ScopedMigration migrate(eventQueue());
assert(transKick);
transKick->process();
};


发件人: Gabe Black [mailto:gabe.bl...@gmail.com]
发送时间: 2021年3月16日 13:55
收件人: Liyichao 
抄送: gem5 users mailing list 
主题: Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM mode with 
more than 1 core

Yes exactly, did that help?

Gabe

On Mon, Mar 15, 2021 at 10:29 PM Liyichao 
mailto:liyic...@huawei.com>> wrote:
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
MmioVirtIO::kick()
{
DPRINTF(VIOIface, "kick(): Sending interrupt...\n");
EventQueue::ScopedMigration migrate(eventQueue());
setInterrupts(interruptStatus | INT_USED_RING);
}

发件人: Gabe Black [mailto:gabe.bl...@gmail.com]
发送时间: 2021年3月16日 8:44
收件人: Liyichao mailto:liyic...@huawei.com>>
抄送: gem5 users mailing list mailto:gem5-users@gem5.org>>
主题: Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM mode with 
more than 1 core

I think what you want to do is in the kick() functions in MmioVirtIO and 
PciVirtIO, you want to declare a ScopedMigration at the start of the function, 
and pass its constructor the result of the eventQueue() method. The SimObject 
class inherits from EventManager and knows what event queue it's supposed to 
use, and that's what eventQueue returns. When you declare a ScopedMigration, it 
will handle the locking correctly and move over to that queue, and when it goes 
out of scope (at the end of the function) it will put everything back.

Please give that a try, and if it works for you (I don't have a way to test it 
myself) put up a review so we can get a fix checked in.

Gabe

On Mon, Mar 15, 2021 at 5:28 PM Liyichao 
mailto:liyic...@huawei.com>> wrote:
Thanks for your explaination.In O3 type with 
multi-core 9P is ok.


发件人： Gabe Blackmailto:gabe.bl...@gmail.com>>
收件人： gem5 users mailing listmailto:gem5-users@gem5.org>>
抄送： Liyichaomailto:liyic...@huawei.com>>
主题： Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM mode with 
more than 1 core
时间： 2021-03-16 07:24:15

I haven't looked at the code yet, but this is probably because the v9 
implementation is getting asynchronous input which might be received by one 
thread, which then tries to schedule an event on an event queue associated with 
another queue. Most of the time this is not an issue since gem5 is usually 
single threaded, but when using multiple cores with KVM, each core runs in its 
own thread. There's a way to add events to the event queue in another thread 
safely (ScopedMigration) which I'm assuming the v9 code is not using.

Gabe

On Sun, Mar 7, 2021 at 8:38 PM Liyichao via gem5-users 
mailto:gem5-users@gem5.org>> wrote:
Hi All:

 When I use –vio-9p with fs_bigLITTLE.py, 1 core the mount cmd was ok, 
but more than 1 core, 

[gem5-users] Re: gem5 crash when mount by vio-9p protocol in KVM mode with more than 1 core

[Gabe Black via gem5-users]

Basically you want to make sure you've moved to the right event queue by
the time any code you call tries to schedule an event. The VirtIO devices
themselves don't seem to, but the code they're calling (interacting with
other devices, sending transactions to the memory system) could be. If it
doesn't work in kick(), then there may be a call earlier which is causing
problems. This is only necessary on code paths that are called
asynchronously, like when you get poked from the other process running the
diod daemon for instance. Basically you want to always and only create a
ScopedMigration when called asynchronously and when something that happens
during that asynchronous call might directly or indirectly cause an event
to be scheduled on the event queue.

I think Andreas has a lot of familiarity with this area, so hopefully he
can chime in and let us know if we're on the right track.

Gabe

On Mon, Mar 15, 2021 at 10:39 PM Liyichao  wrote:

> Or you mean the ScopedMigration needs to be declared in
> VitIO9PBase::sendMsg in fs9p.cc before kick() be called?
>
>
>
>
>
> void
>
> VirtIO9PBase::sendRMsg(const P9MsgHeader , const uint8_t *data,
> size_t size)
>
> {
>
> DPRINTF(VIO9P, "Sending RMsg\n");
>
> EventQueue::ScopedMigration migrate(eventQueue());
>
> dumpMsg(header, data, size);
>
> DPRINTF(VIO9P, "\tPending transactions: %i\n", pendingTransactions.
> size());
>
> assert(header.len >= sizeof(header));
>
>
>
> VirtDescriptor *main_desc(pendingTransactions[header.tag]);
>
> pendingTransactions.erase(header.tag);
>
>
>
> // Find the first output descriptor
>
> VirtDescriptor *out_desc(main_desc);
>
> while (out_desc && !out_desc->isOutgoing())
>
> out_desc = out_desc->next();
>
> if (!out_desc)
>
> panic("sendRMsg: Framing error, no output descriptor.\n");
>
>
>
> P9MsgHeader header_out(htop9(header));
>
> header_out.len = htop9(sizeof(P9MsgHeader) + size);
>
>
>
> out_desc->chainWrite(0, (uint8_t *)_out, sizeof(header_out));
>
> out_desc->chainWrite(sizeof(header_out), data, size);
>
>
>
> queue.produceDescriptor(main_desc, sizeof(P9MsgHeader) + size);
>
> kick();
>
> }
>
>
>
>
> --
>
> 李翼超（Charlie）
>
>
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
> 部门：计算系统与组件开发部 [云与计算BG]
>
> 手 机：15858232899
> 电子邮件：liyic...@huawei.com
>
> 地址：中国(China)-杭州(Hangzhou)-滨江区江淑路360号华为杭州研发中心Z4# [3-A06]
> --
>
>  本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *发件人:* Liyichao
> *发送时间:* 2021年3月16日 13:30
> *收件人:* 'Gabe Black' 
> *抄送:* gem5 users mailing list 
> *主题:* 答复: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
>
>
>
> 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
>
> MmioVirtIO::kick()
>
> {
>
> DPRINTF(VIOIface, "kick(): Sending interrupt...\n");
>
> EventQueue::ScopedMigration migrate(eventQueue());
>
> setInterrupts(interruptStatus | INT_USED_RING);
>
> }
>
>
>
> *发件人:* Gabe Black [mailto:gabe.bl...@gmail.com ]
> *发送时间:* 2021年3月16日 8:44
> *收件人:* Liyichao 
> *抄送:* gem5 users mailing list 
> *主题:* Re: [gem5-users] gem5 crash when mount by vio-9p protocol in KVM
> mode with more than 1 core
>
>
>
> I think what you want to do is in the kick() functions in MmioVirtIO and
> PciVirtIO, you want to declare a ScopedMigration at the start of the
> function, and pass its constructor the result of the eventQueue() method.
> The SimObject class inherits from EventManager and knows what event queue
> it's supposed to use, and that's what eventQueue returns. When you declare
> a ScopedMigration, it will handle the locking correctly and move over to
> that queue, and when it goes out of scope (at the end of the function) it
> will put everything back.
>
>
>
> Please give that a try, and if it works for you (I don't have a way to
> test it myself) put up a review so we can get a fix checked in.
>
>
>
> Gabe
>
>
>
> On Mon, Mar 15, 2021 at 5:28 PM Liyichao  wrote:
>
> Thanks for your explaination.In O3 type with multi-core 9P is ok.
>
>
> *发件人： *Gabe Black
>
> *收件人： *gem5