> 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.
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! - 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
