Hi Bjoern, As Jason said, we do use the x86 ISA regularly inside AMD, though we primarily use SE mode. The FS mode support was developed with the goal of getting Linux to boot, so I'm not surprised it doesn't work for other OSes. I don't know how widely used x86 FS is.
The out-of-sequence Exec trace entry for O3 could be due to the way exec trace entries are timestamped; the information is collected over the course of the instruction's execution but only printed at commit, so it could be that the timestamp is added in execute. I think I've seen this before, but I'd have to look more closely at the code to remember the details. Everything else you mention sounds like a real bug though. FP support (esp. x87 rather than SSE) has never been all that solid. Are you using my locked access patch (http://reviews.gem5.org/r/2691/)? If not, atomic accesses are not truly atomic with the O3 CPU, which could be causing some problems. Thanks for all the effort and bug fixes! Please keep them coming! Steve On Mon, Apr 11, 2016 at 4:58 PM Bjoern A. Zeeb < [email protected]> wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
