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 <liyic...@huawei.com> 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 &cp) const override;
>
> void unserialize(CheckpointIn &cp) 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' <gabe.bl...@gmail.com>
> *抄送:* gem5 users mailing list <gem5-users@gem5.org>
> *主题:* 答复: [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 &cp) const override;
>
> void unserialize(CheckpointIn &cp) 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 <gabe.bl...@gmail.com>]
> *发送时间:* 2021年3月16日 13:55
> *收件人:* Liyichao <liyic...@huawei.com>
> *抄送:* gem5 users mailing list <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 <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 <liyic...@huawei.com>
> *抄送:* gem5 users mailing list <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 <liyic...@huawei.com> wrote:
>
> Thanks for your explaination.In O3 type with multi-core 9P is ok.
>
> *发件人： *Gabe Black<gabe.bl...@gmail.com>
>
> *收件人： *gem5 users mailing list<gem5-users@gem5.org>
>
> *抄送： *Liyichao<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 <
> 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, mount cmd will cause GEM5 crash
>
>
>
> 1core:
>
> Gem5 cmd: ./build/ARM/gem5.opt --debug-flags=Exec -d
> /home/l00515693/m5out configs/example/arm/fs_bigLITTLE.py --cpu-type=kvm
> --kernel=vmlinux --machine-type=VExpress_GEM5_V1
> --disk=expanded-aarch64-ubuntu-trusty-headless.img --caches
> --big-cpu-clock=2.6GHz --little-cpu-clock=2.6GHz --big-cpus=1
> --little-cpus=0 --mem-size=4GB --param 'system.realview.gic.gem5_extensions
> = True' --bootscript=./test.rcS --vio-9p
>
> Mount cmd in guest OS: mount -t 9p -o
> trans=virtio,version=9p2000.L,aname=/home/l00515693/m5out/9p/share gem5
> /mnt/9p
>
> root@charlie:~# df -h
>
> Filesystem Size Used Avail Use% Mounted on
>
> /dev/root 9.9G 3.3G 6.2G 35% /
>
> devtmpfs 2.0G 4.0K 2.0G 1% /dev
>
> none 4.0K 0 4.0K 0% /sys/fs/cgroup
>
> none 396M 52K 396M 1% /run
>
> none 5.0M 0 5.0M 0% /run/lock
>
> none 2.0G 0 2.0G 0% /run/shm
>
> none 100M 0 100M 0% /run/user
>
> gem5 2.9T 1.8T 989G 65% /mnt/9p
>
>
>
>
>
>
>
> 2core:
>
> Gem5 cmd: ./build/ARM/gem5.opt --debug-flags=Exec -d
> /home/l00515693/m5out configs/example/arm/fs_bigLITTLE.py --cpu-type=kvm
> --kernel=vmlinux --machine-type=VExpress_GEM5_V1
> --disk=expanded-aarch64-ubuntu-trusty-headless.img --caches
> --big-cpu-clock=2.6GHz --little-cpu-clock=2.6GHz --big-cpus=2
> --little-cpus=0 --mem-size=4GB --param 'system.realview.gic.gem5_extensions
> = True' --bootscript=./test.rcS --vio-9p
>
>
>
> Mount cmd in guest OS: mount -t 9p -o
> trans=virtio,version=9p2000.L,aname=/home/l00515693/m5out/9p/share gem5
> /mnt/9p
>
>
>
> GEM5 crash info:
>
> gem5.opt: build/ARM/sim/eventq_impl.hh:40: void
> EventQueue::schedule(Event*, Tick, bool): Assertion `when >= getCurTick()'
> failed.
>
> Program aborted at tick 476281849910020
>
> --- BEGIN LIBC BACKTRACE ---
>
> ./build/ARM/gem5.opt(_Z15print_backtracev+0x40)[0xaaaadd24e418]
>
> ./build/ARM/gem5.opt(_Z12abortHandleri+0x5c)[0xaaaadd25efa4]
>
> linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffff9fea5688]
>
> /lib/aarch64-linux-gnu/libc.so.6(raise+0xb0)[0xffff9f6634f8]
>
> --- END LIBC BACKTRACE ---
>
> Aborted (core dumped)
>
>
>
> _______________________________________________
> 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
