On Mon, 11 Apr 2016, Jason Lowe-Power wrote: Hi Jason,
thanks for that quick reply.
There are a number of people who use x86 with gem5. Personally, I use x86 almost exclusively. As I'm sure you know, the initial full-system support was geared towards Linux. My experience is that x86+Linux works pretty well (functionally at least). We have run into a number of x86 bugs over the years, but from my point of view, it's pretty stable. However, I'll admit I'm mostly interested in the memory system, not the core microarchitecture. I haven't spent much time doing performance debugging of the core. I'm happy if it can issue one memory request per cycle. Additionally, I believe the folks at AMD who use gem5 are primarily using the x86 ISA. However, I shouldn't speak for them :). What kinds of problems are you running into? Mostly issues with the system support (interrupts, APIC, etc)? Or are you actually finding issues with the instruction implementations?
Just a few things from the top of my head: Floating point bits crashing gem5 (these I hacked around as I don't need the actual values saved and restored). That's some memory corruption going on there (cvtfp80h_int, cvtfp80l_int). I can go and debug this if someone is interested enough to review the diff later on and get it in. The bus space identifieres were not padded to 6 bytes white space violating the spec (I have an old review around, which I couldn't test on Linux; like none of my other chnages; I should probably get a test setup but ...) The CPUID values are partialy just fantasy and not backed by actual implementations. Whoever started to add the ACPI bit, saying "hey we support this" must have had a very special use case ;-) Would be really good if someone(tm) would actually start providing these bits as it might make a few things easier; I think FreeBSD's bhyve has a minimalistic BSD licensed implementation which might be interesting; I guess aarch64 will want to support that some time as well? x86/interrupts.cc has the wrong offset calculations in one direction, so the APIC bits can never have worked in any proper way. I'll post a patch to review for that soon. I posted a patch for a TLB issue, which is in review, where adding a large page after a regular page would not be handled correctly. I have hit 1-2-3 assertions somewhere in the code, which I generously started to ignore but probably someone(tm) should look at it with me and decide the right way forward. I am still hunting a different what looks like a TLB bug as I am getting a page fault on a no-fault address. It's been a while since I looked at the trace (and I'll try to get a new clean one), but there was a "tick" completely out of sequence in the Exec trace, which to my understanding should not happen. So could also be an O3 bug, as the same code works with the "timing" model for X86_64 w/o problem. And then there was a bit of UART fun; ATA (IDE) I gave up on and started to use virtio instead as it was so utterly old and not quite to spec, .. I'd have to go back and see what else. I've lately cleaned up my patchset so expect some bits; if you (or someone else can help me to check that whatever Linux/X86 people are using doesn't get broken by them, that would be super helpful) as the more I get the patches out of my tree, the more I can focus on my actual work and analysing the remaining problems. And I am happy to take that testing bits off the mailing list ;-) Bjoern _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
