[gem5-users] Re: Adding 9p support to the riscv-fs platform not working
Hi Thilo, My guess is that you need to add a node to the device tree. I would look at the device tree generated for Arm and see if you can pattern match what you need to add for RISC-V. Cheers, Jason On Mon, Oct 2, 2023 at 1:12 AM Thilo Voertler via gem5-users < gem5-users@gem5.org> wrote: > Hi all, > > > > I’m trying to add support for 9p to the riscv-fs platform > (configs/example/gem5_library/riscv-fs.py) similar to the way it was done > for arm systems using the def attach_9p function > (configs/common/FSConfig.py). > > Summary: > > > > When trying to mount on the guest I get an error > > mount -t 9p -o > trans=virtio,version=9p2000.L,aname=/gem5rundir/m5out/9p/share gem5 /mnt/9p > > mount: mounting gem5 on /mnt/9p failed: No such file or directory > > > > The reason seems to be that VirtIO9PDiod device is not set up correctly > under my Platform or Linux so that Linux can find the gem5 tag used for > sharing. > > > > Details: > > I created my own board, which derives from the RiscvBoard and overwrites > the function: > > > > class COSRiscvBoard(RiscvBoard): > > @overrides(AbstractSystemBoard) > > def _setup_io_devices(self) -> None: > > super()._setup_io_devices() > > self.add_riscv_9p() > > def add_riscv_9p(self): > > print(f"Function _setup_board Adding 9p device to platform") > > self.viopci = PciVirtIO(pci_bus=0, pci_dev=1, # Hardcoded for the > platform, Ethernet in RiscV Board is 0 > >pci_func=0, InterruptPin=1, > >InterruptLine=1) > > self.viopci.vio = VirtIO9PDiod() > > viodir = os.path.realpath(os.path.join(m5.options.outdir, "9p")) > > self.viopci.vio.root = os.path.join(viodir, "share") > > self.viopci.vio.socketPath = os.path.join(viodir, "socket") > > os.makedirs(self.viopci.vio.root, exist_ok=True) > > if os.path.exists(self.viopci.vio.socketPath): > > os.remove(self.viopci.vio.socketPath) > > > > self.viopci.host = self.platform.pci_host > > self.viopci.pio = self.iobus.mem_side_ports > > self.viopci.dma = self.iobus.cpu_side_ports > > > > I rebuilt the Linux with virtio9p support as described in > http://old.gem5.org/WA-gem5.html under guest system requirements. During > boot I see the new attached virtio-pci device (in Addition to the Ethernet > device of the platfrom). > > [1.824575] pci-host-generic 3000.pci: host bridge /soc/pci ranges: > > [1.825257] pci-host-generic 3000.pci: No bus range found for > /soc/pci, using [bus 00-ff] > > [1.826709] pci-host-generic 3000.pci: IO > 0x002f00..0x002f00 -> 0x00 > > [1.827637] pci-host-generic 3000.pci: MEM > 0x004000..0x007fff -> 0x00 > > [1.899228] pci-host-generic 3000.pci: ECAM at [mem > 0x3000-0x3fff] for [bus 00-ff] > > [1.902419] pci-host-generic 3000.pci: PCI host bridge to bus > :00 > > [1.902923] pci_bus :00: root bus resource [bus 00-ff] > > [1.903470] pci_bus :00: root bus resource [io 0x-0x] > > [1.904121] pci_bus :00: root bus resource [mem > 0x4000-0x7fff] (bus address [0x-0x3fff]) > > [1.905119] pci :00:00.0: [8086:1075] type 00 class 0x02 > > [1.906011] pci :00:00.0: reg 0x10: [mem 0x4000-0x4001] > > [1.906941] pci :00:00.0: reg 0x30: [mem 0x4000-0x47ff pref] > > *[1.911587] pci :00:01.0: [1af4:1000] type 00 class 0xff* > > *[1.912321] pci :00:01.0: reg 0x10: [io 0x-0x001f]* > > [1.913207] pci :00:01.0: reg 0x30: [mem 0x4000-0x47ff pref] > > [1.923427] pci :00:00.0: BAR 0: assigned [mem > 0x4000-0x4001] > > [1.924118] pci :00:00.0: BAR 6: assigned [mem > 0x4002-0x400207ff pref] > > [1.924809] pci :00:01.0: BAR 6: assigned [mem > 0x40020800-0x40020fff pref] > > [1.925486] pci :00:01.0: BAR 0: assigned [io 0x-0x001f] > > > > However I get an error when loading the virtio-pci driver > > [1.939684] virtio-pci :00:01.0: enabling device ( -> 0001) > > [1.940263] virtio-pci :00:01.0: virtio_pci: leaving for legacy > driver > > [1.940742] virtio-pci: probe of :00:01.0 failed with error -12 > > There is also no device that provides the gem5 tag under > /sys/bus/virtio/drivers/9pnet_virtio/virtio/mount_tag files ( > https://www.kernel.org/doc/Documentation/filesystems/9p.txt) > > root@UCanLinux:~ # ls /sys/bus/virtio/drivers/9pnet_virtio/ > > bindmodule uevent unbind > > I also checked that diod is in the path and I get message that it was > started. > > > > Anyone an idea why it is not working or what I can try to run it again > > > > Best Regards, > > > > Thilo > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org >
[gem5-users] Re: Squashing Instructions after Page Table Fault
On 10/4/2023 10:03 AM, reverent.green--- via gem5-users wrote: Hi Yuan, thank you very much for your detailed response. My understanding of the fault handling in gem5 is getting better and better. Using debug flags, I can trace the control flow during the execution of my code. I am currently inspecting tlb.cc in further detail, but I am still searching for the exact check for my problem. To further specify my question: During the attempt to access kernel memory, the “user/supervisor” (U/S) pagetable attribute is used to check whether this page table belongs to kernel memory or not. If I want to access the memory, it should raise the page table fault. I am looking for this specific check. My goal is, to experiment with gem5 and to customize it. Currently, the instruction is not executed when raising a Page Table Fault. In a first step, I want to change the check in order to execute the instruction although it wants to access kernel memory. So I explicitly search for this check inside this command chain during the Page Fault handling. Thank you very much in advance. Best regards Robin Assuming we're talking about the x86 architecture, line 471 in tlb.cc is where the check in question happens: https://github.com/gem5/gem5/blob/48a40cf2f5182a82de360b7efa497d82e06b1631/src/arch/x86/tlb.cc#L471 Note that the raw bits of the PTE have been abstracted out in the gem5 TLB entry data structure, hence properties such as entry->user. HTH Eliot Moss ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
[gem5-users] Re: Squashing Instructions after Page Table Fault
Hi Yuan, thank you very much for your detailed response. My understanding of the fault handling in gem5 is getting better and better. Using debug flags, I can trace the control flow during the execution of my code. I am currently inspecting tlb.cc in further detail, but I am still searching for the exact check for my problem. To further specify my question: During the attempt to access kernel memory, the “user/supervisor” (U/S) pagetable attribute is used to check whether this page table belongs to kernel memory or not. If I want to access the memory, it should raise the page table fault. I am looking for this specific check. My goal is, to experiment with gem5 and to customize it. Currently, the instruction is not executed when raising a Page Table Fault. In a first step, I want to change the check in order to execute the instruction although it wants to access kernel memory. So I explicitly search for this check inside this command chain during the Page Fault handling. Thank you very much in advance. Best regards Robin Gesendet: Samstag, 30. September 2023 um 01:28 Uhr Von: "Yuan Yao via gem5-users" An: "The gem5 Users mailing list" Cc: "Yuan Yao" Betreff: [gem5-users] Re: Squashing Instructions after Page Table Fault Hi Robin, If I understand it correctly, a Page Table Fault instruction is not squashed but *not executed*. The instruction generating a fault is marked ready to commit. Then, during the commit phase, the fault generated by the instruction is handled. To explain this in more detail let me I take an example of how Page Fault of a load is handled with gem5: 1, DefaultIEW::executeInsts() => ldstQueue.executeLoad(Inst) => inst->InitiateAcc() (dynamic inst) => staticInst->initiateAcc() (static inst) => initiateMemRead (dynamic inst again) => cpu->pushRequest() => LSQ->pushRequest() => Follow this function chain, gem5 will ultimately start the translation via the MMU module. 2, Later after the translation is done, the page fault and the faulty instruction is marked by *translation->finish(...)* in pagetable_walker.cc (via walker:recevTimingResp, assuming that there is a page walk). The 'finish()' function is defined in the O3 pipeline components. In this case: LSQ::SingleDataRequest::finish. 3, Because the faulty instruction is not yet committed, DefaultIEW::executeInsts() will check the instruction again, but this time the instruction is marked as 'TranslationCompleted'. However since , so the instruction will be marked as executed and is forward to the commit stage (iewState->instToCommit(inst)). 4, As the instruction moves to the head of ROB, the commitInst() function of the commit unit will call commitHead(), which further calls cpu->trap(), then fault->invoke() to handle the fault. Different faults have different invoke functions. To your question, please take a look at PageFault::invoke() at arch/x86/faults.cc. The CPU then setup the CR2 register etc and will read the ROM to launch the procedure to transfer control to OS fault handler. (The microrom is defined in romutil.py) 5, And after the page handler is finished the fault instruction (still at the head of ROB) will be re-executed. The above is based on gem5 21.0.0.0 but I don't think the code changes much for the above discussions. Hope this helps. PS. Page access write is checked at the translate function in tlb.cc. Br, Yuan On 9/29/23 12:28, reverent.green--- via gem5-users wrote: A short addition. I also couldn't find a specific check for the user/supervisor Page Table Attribute anywhere. Are there parts in the code, where specific bits are checked or does gem5 uses some other kind of implementation here? Gesendet: Freitag, 29. September 2023 um 12:04 Uhr Von: "reverent.green--- via gem5-users" An: gem5-users@gem5.org Cc: reverent.gr...@web.de Betreff: [gem5-users] Squashing Instructions after Page Table Fault Hello, I am currently trying to locate the code that is used to squash instructions if a Page Table Fault is triggered in the O3 CPU. After using the PageTableWalker Debug Flags, my current guess would be gem5/src/arch/x86/pagetable_walker.cc in line 199. Furthermore I inspected the files in the src/cpu/o3 directory, but couldn't find anything specific to squashing instructions after a fault. Is my assumption correct, that the O3 CPU implementation does not handle these things on its own, but the architectural part of the implementation does it? I am missing something, feel free to point it out. Thank you in advance for your help. Kind regards Robin ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org VARNING: Klicka inte på länkar och öppna inte bilagor om du inte känner igen avsändaren och vet att innehållet är säkert. CAUTION: Do not click on links or open attachments unless you recognise the sender and
