> On Aug. 14, 2014, 10:05 a.m., Andreas Sandberg wrote: > > I'm really not happy about the use of kvm-specific ports magic here. It > > would have been nicer having a m5ops based interface that just passes the > > fault/syscall to the arch-specific code from any CPU model that uses the > > m5ops interface. Specifically, I'm a bit concerned about what would happen > > if you switch in the syscall or fault handler code before you enter into > > gem5. In this case the fault/syscall will be lost since the simulated CPUs > > don't know how to handle the port magic. If you have a good reason to > > believe that this won't be an issue, I'm happy to have this committed. I > > have fixed quite a few switching bugs in the past and I know that things > > like these are likely to come back and bite you and are a pain to diagnose. > > > > Alexandru Dutu wrote: > Right, using m5ops (MMIO) instead of IO ports is a better choice. I have > not thought in detail about switching the CPU model inside the syscall/fault > handler when designing this. You are right though the simulated CPUs will > have to handle those magic I/O ports in this case. > > Alexandru Dutu wrote: > I understant that KVM marks SPTEs as MMIO by setting the reserved bits > and that the linux kernel maps MMIO regions in the portion beyond PAGE_OFFSET > in the kernel virtual address space. However, having any kind of memory > access (code or data) in the syscall handler produces weird page faults. > There seems not to be any issues with ring switching, as it gets into the > syscall handler and executes a couple of instructions there. In addition, > there is no issue if the application code accesses the region marked for MMIO > (with the right permissions in the page table), issues appear when the access > is initiate by an instruction in the syscall handler. I still don't have an > explanation for why this is happening. I might be overlooking some things > here, so I appreciate any comments you might have. Thank you!
I figured out the cause for the weird page faults and got KVM_EXIT_MMIO. Soon, the syscall and page fault handlers will use MMIO. - Alexandru ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2313/#review5250 ----------------------------------------------------------- On Aug. 1, 2014, 3:52 p.m., Alexandru Dutu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2313/ > ----------------------------------------------------------- > > (Updated Aug. 1, 2014, 3:52 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10267:46ad52c66c87 > --------------------------- > kvm, x86: Adding support for SE mode execution > This patch adds methods in KvmCPU model to handle KVM exits caused by syscall > instructions and page faults. These types of exits will be encountered if > KvmCPU is run in SE mode. > > > Diffs > ----- > > src/arch/x86/system.hh c00b5ba43967e7e48a28b7ddc48c9f4afaf2ab76 > src/cpu/kvm/base.hh c00b5ba43967e7e48a28b7ddc48c9f4afaf2ab76 > src/cpu/kvm/base.cc c00b5ba43967e7e48a28b7ddc48c9f4afaf2ab76 > src/cpu/kvm/x86_cpu.hh c00b5ba43967e7e48a28b7ddc48c9f4afaf2ab76 > src/cpu/kvm/x86_cpu.cc c00b5ba43967e7e48a28b7ddc48c9f4afaf2ab76 > > Diff: http://reviews.gem5.org/r/2313/diff/ > > > Testing > ------- > > Quick regressions passed. > > > Thanks, > > Alexandru Dutu > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
