Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
Nope, it doesn't look like it can. It can intercept BRK and BKPT instructions, but not SVC or HLT, which apparently can also be used for semihosting. Gabe On Fri, Nov 15, 2019 at 2:17 PM Gabe Black wrote: > Unless KVM can intercept SVC instructions somehow? Maybe because they sort > of cause an interrupt? I have my doubts, but I'll look into that since if > it's true it would make life a lot easier. > > Gabe > > On Fri, Nov 15, 2019 at 1:24 PM Gabe Black wrote: > >> >> >> On Fri, Nov 15, 2019 at 4:07 AM Giacomo Travaglini < >> giacomo.travagl...@arm.com> wrote: >> >>> Hi Gabe, >>> >>> Yes, as I was mentioning in >>> https://gem5-review.googlesource.com/c/public/gem5/+/22118/5, if fast >>> models implements arm watchpoints (by writing some self hosted debug >>> registers, >>> and not reying on custom made hooks after the PA is evaluated), those >>> trap on VA matches. >>> >> >> These are not actual architected watchpoints (at least as far as I know), >> these are artificial breakpoints, watchpoints, etc, which are provided by >> the model itself. >> >> >>> >>> I would personally love to see m5 pseudo instructions being implemented >>> with arm semishosting, not only for the FastModel use case. >>> From a m5 pow seems like you would just need to change the macro >>> in util/m5/m5op_arm_A64.S >>> (of course you would have to add the implementation in the semihosting >>> files; how does this work with fast models?) >>> >> >> To implement them in most cases would be easy, but the problem is >> supporting them everywhere. The problem (as I attempted to describe in my >> initial email) is that KVM has no notion of semihosting, and as far as I >> can tell no way to hook the appropriate instructions to intercept them. >> >> To summarize, the options are: >> >> Special instructions: Works only in native CPUs. >> Special memory locations: Works in native CPUs and KVM >> Semihosting: Works in native CPUs and fast models. >> >> There isn't anything that works in all CPUs, meaning there needs to be >> different behavior depending on what CPU you're using at the time. That >> could mean different binaries, or a binary that somehow magically detects >> what it should use, or specifying on the command line, or... >> >> Gabe >> >>> ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
Unless KVM can intercept SVC instructions somehow? Maybe because they sort of cause an interrupt? I have my doubts, but I'll look into that since if it's true it would make life a lot easier. Gabe On Fri, Nov 15, 2019 at 1:24 PM Gabe Black wrote: > > > On Fri, Nov 15, 2019 at 4:07 AM Giacomo Travaglini < > giacomo.travagl...@arm.com> wrote: > >> Hi Gabe, >> >> Yes, as I was mentioning in >> https://gem5-review.googlesource.com/c/public/gem5/+/22118/5, if fast >> models implements arm watchpoints (by writing some self hosted debug >> registers, >> and not reying on custom made hooks after the PA is evaluated), those >> trap on VA matches. >> > > These are not actual architected watchpoints (at least as far as I know), > these are artificial breakpoints, watchpoints, etc, which are provided by > the model itself. > > >> >> I would personally love to see m5 pseudo instructions being implemented >> with arm semishosting, not only for the FastModel use case. >> From a m5 pow seems like you would just need to change the macro >> in util/m5/m5op_arm_A64.S >> (of course you would have to add the implementation in the semihosting >> files; how does this work with fast models?) >> > > To implement them in most cases would be easy, but the problem is > supporting them everywhere. The problem (as I attempted to describe in my > initial email) is that KVM has no notion of semihosting, and as far as I > can tell no way to hook the appropriate instructions to intercept them. > > To summarize, the options are: > > Special instructions: Works only in native CPUs. > Special memory locations: Works in native CPUs and KVM > Semihosting: Works in native CPUs and fast models. > > There isn't anything that works in all CPUs, meaning there needs to be > different behavior depending on what CPU you're using at the time. That > could mean different binaries, or a binary that somehow magically detects > what it should use, or specifying on the command line, or... > > Gabe > >> ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
On Fri, Nov 15, 2019 at 4:07 AM Giacomo Travaglini < giacomo.travagl...@arm.com> wrote: > Hi Gabe, > > Yes, as I was mentioning in > https://gem5-review.googlesource.com/c/public/gem5/+/22118/5, if fast > models implements arm watchpoints (by writing some self hosted debug > registers, > and not reying on custom made hooks after the PA is evaluated), those trap > on VA matches. > These are not actual architected watchpoints (at least as far as I know), these are artificial breakpoints, watchpoints, etc, which are provided by the model itself. > > I would personally love to see m5 pseudo instructions being implemented > with arm semishosting, not only for the FastModel use case. > From a m5 pow seems like you would just need to change the macro > in util/m5/m5op_arm_A64.S > (of course you would have to add the implementation in the semihosting > files; how does this work with fast models?) > To implement them in most cases would be easy, but the problem is supporting them everywhere. The problem (as I attempted to describe in my initial email) is that KVM has no notion of semihosting, and as far as I can tell no way to hook the appropriate instructions to intercept them. To summarize, the options are: Special instructions: Works only in native CPUs. Special memory locations: Works in native CPUs and KVM Semihosting: Works in native CPUs and fast models. There isn't anything that works in all CPUs, meaning there needs to be different behavior depending on what CPU you're using at the time. That could mean different binaries, or a binary that somehow magically detects what it should use, or specifying on the command line, or... Gabe > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
Hi Gabe, Yes, as I was mentioning in https://gem5-review.googlesource.com/c/public/gem5/+/22118/5, if fast models implements arm watchpoints (by writing some self hosted debug registers, and not reying on custom made hooks after the PA is evaluated), those trap on VA matches. I would personally love to see m5 pseudo instructions being implemented with arm semishosting, not only for the FastModel use case. From a m5 pow seems like you would just need to change the macro in util/m5/m5op_arm_A64.S (of course you would have to add the implementation in the semihosting files; how does this work with fast models?) From: Gabe Black Sent: 15 November 2019 01:46 To: Giacomo Travaglini Cc: gem5 Developer List Subject: Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls FYI I base that not on anything in the documentation (it's never mentioned), but the fact that if I pick an address space that's physical, I get a vague "that didn't work" error from the fast models. Gabe On Thu, Nov 14, 2019 at 5:45 PM Gabe Black mailto:gabebl...@google.com>> wrote: Arg. Unfortunately it looks like you can only set watchpoints based on virtual addresses, not physical addresses. I may still have to go the semihosting hook route, and that means yet another flavor of m5 binary. I think something I'm going to try to tackle is coming up with a way to detect what mechanism to use from within the simulation, which is actually pretty tricky since it may change across checkpoints, CPU switches, etc. Perhaps some sort of coprocessor register or something? It will almost certainly need to be ISA specific. Gabe On Thu, Nov 14, 2019 at 1:38 AM Giacomo Travaglini mailto:giacomo.travagl...@arm.com>> wrote: Hi Gabe, It's good that you've found a solution. Just so you know, semihosting is already implemented in gem5-arm, so it would be easy to extend it in order to support pseudo instructions. Giacomo From: gem5-dev mailto:gem5-dev-boun...@gem5.org>> on behalf of Gabe Black mailto:gabebl...@google.com>> Sent: 14 November 2019 04:55 To: gem5 Developer List mailto:gem5-dev@gem5.org>> Subject: Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls Thinking about this more, it occurs to me it should be possible to set a watchpoint through IRIS which watches for accesses to the m5 device region. That may help solve this issue. Gabe On Wed, Nov 13, 2019 at 8:12 PM Gabe Black mailto:gabebl...@google.com>> wrote: > Hi folks. I'm looking for a way to enable the m5 utility/pseudo > instructions with fast model CPUs, and it's a little more complicated than > I'd initially assumed. > > I knew there was a memory mapped mechanism to support the pseudo > instructions, and that that was added to enable those instructions in KVM > mode. That is done using the finalizePhysical method on the TLBs which > detects accesses within certain ranges, and then redirects them to memory > mapped IPRs (an Alpha-ism) which handle the pseudo instruction. > > The problem with this approach and fast models is that, for starters, the > port to memory comes out of the fast model already collected from all the > cores that make up a cluster. It isn't possible as far as I can tell to > determine which core (and hence which context) a given request came from to > plumb up the "IPR" access correctly. > > Then beyond that, the accesses come out an AMBA flavor of TLM (the systemc > communication mechanism), and those have to be translate first to regular > TLM, and then to gem5's protocol using separate bridge objects. There isn't > anywhere to insert a call to the finalizePhysical call or equivalent to > intercept requests to the psuedo instruction device. > > One possible solution would be to use a mechanism called semihosting which > is supported by the fast models. Basically, using the SVC instruction with > a magic number (SVC is usually used for system calls) will trap into the > simulation mechanism. The value in R0 is supposed to say what service you > want (read from a file, write to stdout, etc), and then additional > parameters are in a blob pointed to by r1. The IRIS API, a debug API we're > using to implement ThreadContexts for the fast models, has an interface to > trap semihosting events, so it should be possible to run semihosting > instructions, capture them with the IRIS interface, and use that (which > knows what ThreadContext is relevant) to implement a call into the pseudo > instructions. > > This *should* work for fast model CPUs, and it shouldn't be difficult to > add into the native gem5 CPUs where we control what all the instructions > do. KVM, on the other hand, is a bit trickier. I've been digging around in > the KVM and QE
Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
FYI I base that not on anything in the documentation (it's never mentioned), but the fact that if I pick an address space that's physical, I get a vague "that didn't work" error from the fast models. Gabe On Thu, Nov 14, 2019 at 5:45 PM Gabe Black wrote: > Arg. Unfortunately it looks like you can only set watchpoints based on > virtual addresses, not physical addresses. I may still have to go the > semihosting hook route, and that means yet another flavor of m5 binary. I > think something I'm going to try to tackle is coming up with a way to > detect what mechanism to use from within the simulation, which is actually > pretty tricky since it may change across checkpoints, CPU switches, etc. > Perhaps some sort of coprocessor register or something? It will almost > certainly need to be ISA specific. > > Gabe > > On Thu, Nov 14, 2019 at 1:38 AM Giacomo Travaglini < > giacomo.travagl...@arm.com> wrote: > >> Hi Gabe, >> >> >> It's good that you've found a solution. >> Just so you know, semihosting is already implemented in gem5-arm, so it >> would be easy to extend it >> in order to support pseudo instructions. >> >> Giacomo >> -- >> *From:* gem5-dev on behalf of Gabe Black < >> gabebl...@google.com> >> *Sent:* 14 November 2019 04:55 >> *To:* gem5 Developer List >> *Subject:* Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo >> instructions, and system calls >> >> Thinking about this more, it occurs to me it should be possible to set a >> watchpoint through IRIS which watches for accesses to the m5 device >> region. >> That may help solve this issue. >> >> Gabe >> >> On Wed, Nov 13, 2019 at 8:12 PM Gabe Black wrote: >> >> > Hi folks. I'm looking for a way to enable the m5 utility/pseudo >> > instructions with fast model CPUs, and it's a little more complicated >> than >> > I'd initially assumed. >> > >> > I knew there was a memory mapped mechanism to support the pseudo >> > instructions, and that that was added to enable those instructions in >> KVM >> > mode. That is done using the finalizePhysical method on the TLBs which >> > detects accesses within certain ranges, and then redirects them to >> memory >> > mapped IPRs (an Alpha-ism) which handle the pseudo instruction. >> > >> > The problem with this approach and fast models is that, for starters, >> the >> > port to memory comes out of the fast model already collected from all >> the >> > cores that make up a cluster. It isn't possible as far as I can tell to >> > determine which core (and hence which context) a given request came >> from to >> > plumb up the "IPR" access correctly. >> > >> > Then beyond that, the accesses come out an AMBA flavor of TLM (the >> systemc >> > communication mechanism), and those have to be translate first to >> regular >> > TLM, and then to gem5's protocol using separate bridge objects. There >> isn't >> > anywhere to insert a call to the finalizePhysical call or equivalent to >> > intercept requests to the psuedo instruction device. >> > >> > One possible solution would be to use a mechanism called semihosting >> which >> > is supported by the fast models. Basically, using the SVC instruction >> with >> > a magic number (SVC is usually used for system calls) will trap into the >> > simulation mechanism. The value in R0 is supposed to say what service >> you >> > want (read from a file, write to stdout, etc), and then additional >> > parameters are in a blob pointed to by r1. The IRIS API, a debug API >> we're >> > using to implement ThreadContexts for the fast models, has an interface >> to >> > trap semihosting events, so it should be possible to run semihosting >> > instructions, capture them with the IRIS interface, and use that (which >> > knows what ThreadContext is relevant) to implement a call into the >> pseudo >> > instructions. >> > >> > This *should* work for fast model CPUs, and it shouldn't be difficult to >> > add into the native gem5 CPUs where we control what all the instructions >> > do. KVM, on the other hand, is a bit trickier. I've been digging around >> in >> > the KVM and QEMU source, and while QEMU says it supports semihosting, I >> > don't see anything that makes it look like it supports semihosting *and* >> > KVM at the same time. That may work through some magic I'm not seeing, >&
Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
Arg. Unfortunately it looks like you can only set watchpoints based on virtual addresses, not physical addresses. I may still have to go the semihosting hook route, and that means yet another flavor of m5 binary. I think something I'm going to try to tackle is coming up with a way to detect what mechanism to use from within the simulation, which is actually pretty tricky since it may change across checkpoints, CPU switches, etc. Perhaps some sort of coprocessor register or something? It will almost certainly need to be ISA specific. Gabe On Thu, Nov 14, 2019 at 1:38 AM Giacomo Travaglini < giacomo.travagl...@arm.com> wrote: > Hi Gabe, > > > It's good that you've found a solution. > Just so you know, semihosting is already implemented in gem5-arm, so it > would be easy to extend it > in order to support pseudo instructions. > > Giacomo > -- > *From:* gem5-dev on behalf of Gabe Black < > gabebl...@google.com> > *Sent:* 14 November 2019 04:55 > *To:* gem5 Developer List > *Subject:* Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo > instructions, and system calls > > Thinking about this more, it occurs to me it should be possible to set a > watchpoint through IRIS which watches for accesses to the m5 device region. > That may help solve this issue. > > Gabe > > On Wed, Nov 13, 2019 at 8:12 PM Gabe Black wrote: > > > Hi folks. I'm looking for a way to enable the m5 utility/pseudo > > instructions with fast model CPUs, and it's a little more complicated > than > > I'd initially assumed. > > > > I knew there was a memory mapped mechanism to support the pseudo > > instructions, and that that was added to enable those instructions in KVM > > mode. That is done using the finalizePhysical method on the TLBs which > > detects accesses within certain ranges, and then redirects them to memory > > mapped IPRs (an Alpha-ism) which handle the pseudo instruction. > > > > The problem with this approach and fast models is that, for starters, the > > port to memory comes out of the fast model already collected from all the > > cores that make up a cluster. It isn't possible as far as I can tell to > > determine which core (and hence which context) a given request came from > to > > plumb up the "IPR" access correctly. > > > > Then beyond that, the accesses come out an AMBA flavor of TLM (the > systemc > > communication mechanism), and those have to be translate first to regular > > TLM, and then to gem5's protocol using separate bridge objects. There > isn't > > anywhere to insert a call to the finalizePhysical call or equivalent to > > intercept requests to the psuedo instruction device. > > > > One possible solution would be to use a mechanism called semihosting > which > > is supported by the fast models. Basically, using the SVC instruction > with > > a magic number (SVC is usually used for system calls) will trap into the > > simulation mechanism. The value in R0 is supposed to say what service you > > want (read from a file, write to stdout, etc), and then additional > > parameters are in a blob pointed to by r1. The IRIS API, a debug API > we're > > using to implement ThreadContexts for the fast models, has an interface > to > > trap semihosting events, so it should be possible to run semihosting > > instructions, capture them with the IRIS interface, and use that (which > > knows what ThreadContext is relevant) to implement a call into the pseudo > > instructions. > > > > This *should* work for fast model CPUs, and it shouldn't be difficult to > > add into the native gem5 CPUs where we control what all the instructions > > do. KVM, on the other hand, is a bit trickier. I've been digging around > in > > the KVM and QEMU source, and while QEMU says it supports semihosting, I > > don't see anything that makes it look like it supports semihosting *and* > > KVM at the same time. That may work through some magic I'm not seeing, > but > > if I can't find it I can't reimplement it in gem5 :-). > > > > It looks like KVM used to support a hypercall exit, but I see a change > > from the Xen hypervisor guys that made KVM eat all hypercalls internally > > and not forward any of them to userspace. They say to use KVM_EXIT_IO on > > x86 and KVM_EXIT_MMIO on non-x86 systems to get the same effect. In > either > > case, I think that forces us into what we have now, where the m5 binary > > uses magical addresses to do its work. I think we could switch to using > an > > IO port on x86 though, and a small window on ARM. In all cases we have > > access to t
Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
Hi Gabe, It's good that you've found a solution. Just so you know, semihosting is already implemented in gem5-arm, so it would be easy to extend it in order to support pseudo instructions. Giacomo From: gem5-dev on behalf of Gabe Black Sent: 14 November 2019 04:55 To: gem5 Developer List Subject: Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls Thinking about this more, it occurs to me it should be possible to set a watchpoint through IRIS which watches for accesses to the m5 device region. That may help solve this issue. Gabe On Wed, Nov 13, 2019 at 8:12 PM Gabe Black wrote: > Hi folks. I'm looking for a way to enable the m5 utility/pseudo > instructions with fast model CPUs, and it's a little more complicated than > I'd initially assumed. > > I knew there was a memory mapped mechanism to support the pseudo > instructions, and that that was added to enable those instructions in KVM > mode. That is done using the finalizePhysical method on the TLBs which > detects accesses within certain ranges, and then redirects them to memory > mapped IPRs (an Alpha-ism) which handle the pseudo instruction. > > The problem with this approach and fast models is that, for starters, the > port to memory comes out of the fast model already collected from all the > cores that make up a cluster. It isn't possible as far as I can tell to > determine which core (and hence which context) a given request came from to > plumb up the "IPR" access correctly. > > Then beyond that, the accesses come out an AMBA flavor of TLM (the systemc > communication mechanism), and those have to be translate first to regular > TLM, and then to gem5's protocol using separate bridge objects. There isn't > anywhere to insert a call to the finalizePhysical call or equivalent to > intercept requests to the psuedo instruction device. > > One possible solution would be to use a mechanism called semihosting which > is supported by the fast models. Basically, using the SVC instruction with > a magic number (SVC is usually used for system calls) will trap into the > simulation mechanism. The value in R0 is supposed to say what service you > want (read from a file, write to stdout, etc), and then additional > parameters are in a blob pointed to by r1. The IRIS API, a debug API we're > using to implement ThreadContexts for the fast models, has an interface to > trap semihosting events, so it should be possible to run semihosting > instructions, capture them with the IRIS interface, and use that (which > knows what ThreadContext is relevant) to implement a call into the pseudo > instructions. > > This *should* work for fast model CPUs, and it shouldn't be difficult to > add into the native gem5 CPUs where we control what all the instructions > do. KVM, on the other hand, is a bit trickier. I've been digging around in > the KVM and QEMU source, and while QEMU says it supports semihosting, I > don't see anything that makes it look like it supports semihosting *and* > KVM at the same time. That may work through some magic I'm not seeing, but > if I can't find it I can't reimplement it in gem5 :-). > > It looks like KVM used to support a hypercall exit, but I see a change > from the Xen hypervisor guys that made KVM eat all hypercalls internally > and not forward any of them to userspace. They say to use KVM_EXIT_IO on > x86 and KVM_EXIT_MMIO on non-x86 systems to get the same effect. In either > case, I think that forces us into what we have now, where the m5 binary > uses magical addresses to do its work. I think we could switch to using an > IO port on x86 though, and a small window on ARM. In all cases we have > access to the relevant thread context so we don't need to worry about > having a big window for passing around parameters. > > > All this also brings up an idea I had a while ago where I wanted to unify > and generalize the pseudo instruction and system call catching code. In > both cases, gem5 is intercepting a particular instruction and then doing > something special, and it would be nice to have those work in the same way, > and to be able to add new types of calls into gem5 to, for instance, > emulate BIOS interrupts. The idea would be to have a system call call into > an actual stub, but then the stub would use the pseudo instruction > mechanism to call into gem5. gem5 would then know to do a system call or > whatever. This would remove one more difference between SE and FS mode > which would also be nice. > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are n
Re: [gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
Thinking about this more, it occurs to me it should be possible to set a watchpoint through IRIS which watches for accesses to the m5 device region. That may help solve this issue. Gabe On Wed, Nov 13, 2019 at 8:12 PM Gabe Black wrote: > Hi folks. I'm looking for a way to enable the m5 utility/pseudo > instructions with fast model CPUs, and it's a little more complicated than > I'd initially assumed. > > I knew there was a memory mapped mechanism to support the pseudo > instructions, and that that was added to enable those instructions in KVM > mode. That is done using the finalizePhysical method on the TLBs which > detects accesses within certain ranges, and then redirects them to memory > mapped IPRs (an Alpha-ism) which handle the pseudo instruction. > > The problem with this approach and fast models is that, for starters, the > port to memory comes out of the fast model already collected from all the > cores that make up a cluster. It isn't possible as far as I can tell to > determine which core (and hence which context) a given request came from to > plumb up the "IPR" access correctly. > > Then beyond that, the accesses come out an AMBA flavor of TLM (the systemc > communication mechanism), and those have to be translate first to regular > TLM, and then to gem5's protocol using separate bridge objects. There isn't > anywhere to insert a call to the finalizePhysical call or equivalent to > intercept requests to the psuedo instruction device. > > One possible solution would be to use a mechanism called semihosting which > is supported by the fast models. Basically, using the SVC instruction with > a magic number (SVC is usually used for system calls) will trap into the > simulation mechanism. The value in R0 is supposed to say what service you > want (read from a file, write to stdout, etc), and then additional > parameters are in a blob pointed to by r1. The IRIS API, a debug API we're > using to implement ThreadContexts for the fast models, has an interface to > trap semihosting events, so it should be possible to run semihosting > instructions, capture them with the IRIS interface, and use that (which > knows what ThreadContext is relevant) to implement a call into the pseudo > instructions. > > This *should* work for fast model CPUs, and it shouldn't be difficult to > add into the native gem5 CPUs where we control what all the instructions > do. KVM, on the other hand, is a bit trickier. I've been digging around in > the KVM and QEMU source, and while QEMU says it supports semihosting, I > don't see anything that makes it look like it supports semihosting *and* > KVM at the same time. That may work through some magic I'm not seeing, but > if I can't find it I can't reimplement it in gem5 :-). > > It looks like KVM used to support a hypercall exit, but I see a change > from the Xen hypervisor guys that made KVM eat all hypercalls internally > and not forward any of them to userspace. They say to use KVM_EXIT_IO on > x86 and KVM_EXIT_MMIO on non-x86 systems to get the same effect. In either > case, I think that forces us into what we have now, where the m5 binary > uses magical addresses to do its work. I think we could switch to using an > IO port on x86 though, and a small window on ARM. In all cases we have > access to the relevant thread context so we don't need to worry about > having a big window for passing around parameters. > > > All this also brings up an idea I had a while ago where I wanted to unify > and generalize the pseudo instruction and system call catching code. In > both cases, gem5 is intercepting a particular instruction and then doing > something special, and it would be nice to have those work in the same way, > and to be able to add new types of calls into gem5 to, for instance, > emulate BIOS interrupts. The idea would be to have a system call call into > an actual stub, but then the stub would use the pseudo instruction > mechanism to call into gem5. gem5 would then know to do a system call or > whatever. This would remove one more difference between SE and FS mode > which would also be nice. > ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] ARM semihosting, KVM, fast models, pseudo instructions, and system calls
Hi folks. I'm looking for a way to enable the m5 utility/pseudo instructions with fast model CPUs, and it's a little more complicated than I'd initially assumed. I knew there was a memory mapped mechanism to support the pseudo instructions, and that that was added to enable those instructions in KVM mode. That is done using the finalizePhysical method on the TLBs which detects accesses within certain ranges, and then redirects them to memory mapped IPRs (an Alpha-ism) which handle the pseudo instruction. The problem with this approach and fast models is that, for starters, the port to memory comes out of the fast model already collected from all the cores that make up a cluster. It isn't possible as far as I can tell to determine which core (and hence which context) a given request came from to plumb up the "IPR" access correctly. Then beyond that, the accesses come out an AMBA flavor of TLM (the systemc communication mechanism), and those have to be translate first to regular TLM, and then to gem5's protocol using separate bridge objects. There isn't anywhere to insert a call to the finalizePhysical call or equivalent to intercept requests to the psuedo instruction device. One possible solution would be to use a mechanism called semihosting which is supported by the fast models. Basically, using the SVC instruction with a magic number (SVC is usually used for system calls) will trap into the simulation mechanism. The value in R0 is supposed to say what service you want (read from a file, write to stdout, etc), and then additional parameters are in a blob pointed to by r1. The IRIS API, a debug API we're using to implement ThreadContexts for the fast models, has an interface to trap semihosting events, so it should be possible to run semihosting instructions, capture them with the IRIS interface, and use that (which knows what ThreadContext is relevant) to implement a call into the pseudo instructions. This *should* work for fast model CPUs, and it shouldn't be difficult to add into the native gem5 CPUs where we control what all the instructions do. KVM, on the other hand, is a bit trickier. I've been digging around in the KVM and QEMU source, and while QEMU says it supports semihosting, I don't see anything that makes it look like it supports semihosting *and* KVM at the same time. That may work through some magic I'm not seeing, but if I can't find it I can't reimplement it in gem5 :-). It looks like KVM used to support a hypercall exit, but I see a change from the Xen hypervisor guys that made KVM eat all hypercalls internally and not forward any of them to userspace. They say to use KVM_EXIT_IO on x86 and KVM_EXIT_MMIO on non-x86 systems to get the same effect. In either case, I think that forces us into what we have now, where the m5 binary uses magical addresses to do its work. I think we could switch to using an IO port on x86 though, and a small window on ARM. In all cases we have access to the relevant thread context so we don't need to worry about having a big window for passing around parameters. All this also brings up an idea I had a while ago where I wanted to unify and generalize the pseudo instruction and system call catching code. In both cases, gem5 is intercepting a particular instruction and then doing something special, and it would be nice to have those work in the same way, and to be able to add new types of calls into gem5 to, for instance, emulate BIOS interrupts. The idea would be to have a system call call into an actual stub, but then the stub would use the pseudo instruction mechanism to call into gem5. gem5 would then know to do a system call or whatever. This would remove one more difference between SE and FS mode which would also be nice. ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
