Glad you all seem to be figuring this out. I think we should do runtime rather than compile-time detection though, as some people may have mixed clusters they want to run the same binary on, or may cross-compile.
Steve On Wed, Jan 21, 2015 at 3:30 PM, Dutu, Alexandru via gem5-dev < gem5-dev@gem5.org> wrote: > From AMD's system programming manual: > > SYSCALL > New selectors are loaded, without permission checking (see above), as > follows: > > Bits 47:32 of the STAR register specify the selector that is copied into > the CS register. > Bits 47:32 of the STAR register + 8 specify the selector that is copied > into the SS register. > The CS_base and the SS_base are both forced to zero. > The CS_limit and the SS_limit are both forced to 4 Gbyte. > The CS segment attributes are set to execute/read 64-bit code with a CPL > of zero. > The SS segment attributes are set to read/write and expand-up with a > 64-bit stack referenced by RSP. > > SYSRET > > When a system procedure performs a SYSRET back to application software, > the CS selector is updated from bits 63:50 of the STAR register > (STAR.SYSRET_CS) as follows: > If the return is to 32-bit mode (legacy or compatibility), CS is updated > with the value of STAR.SYSRET_CS. > If the return is to 64-bit mode, CS is updated with the value of > STAR.SYSRET_CS + 16. > In both cases, the CPL is forced to 3, effectively ignoring STAR bits > 49:48. The SS selector is updated to point to the next descriptor-table > entry after the CS descriptor (STAR.SYSRET_CS + 8), and its RPL is not > forced to 3. > > I am wondering if we could detect the CPU vendor with CPUID and have > different setup of the GDT based on the platform you are running on. Could > scons actually detect this at build time? > > Best, > Alex > ________________________________________ > From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Gabe Black via > gem5-dev [gem5-dev@gem5.org] > Sent: Wednesday, January 21, 2015 3:48 PM > To: mike upton; Default; Gabe Black > Subject: Re: [gem5-dev] Review Request 2557: x86: kvm: Fix the KVM CPU in > SE and FS on Intel CPUs. > > > On Jan. 21, 2015, 9:22 p.m., mike upton wrote: > > > src/arch/x86/process.cc, lines 218-237 > > > <http://reviews.gem5.org/r/2557/diff/2/?file=42948#file42948line218> > > > > > > For AMD systems, the sys descriptors need to come first. On intel > systems they need to come second. > > > > > > I do not know how to resolve... > > > > mike upton wrote: > > I have been debugging why patch rb2557 breaks AMD KVM functionality. > > > > > > > > > > I was hoping to get to code that would work on both intel and AMD > platforms, but am not there yet. > > > > > > > > > > This patch is to be applied on top of rb2557.patch. > > > > > > > > > > There are 2 main issues, neither of which I understand well enough > to take much further. > > > > > > > > > > The first issue is that the order that the segment descriptors get > instantiated in the GDT table seems to matter between AMD and Intel, and > they seem to be mutually incompatible. > > > > > > > > > > AMD wants: > > > > csSys > > > > dsSys > > > > ds > > > > cs > > > > > > > > > > Intel wants: > > > > ds > > > > cs > > > > dsSys > > > > csSys > > > > > > > > > > I am not sure the relative ordering of ds and cs within a class > matters, only that AMD wants the Sys ones first, and Intel wants them > second. > > > > > > > > > > There is also an issue with how 'star' gets defined. > > > > I can not make the Intel code work for AMD. > > > > > > > > > > Both issues are addressed in this patch. > > > > > > > > > > The patch makes the AMD system work, but breaks Intel functionality. > > > > > > > > > > I am also not sure how to upload this into review board. Do I create > a separate patch from TOT, or can I somehow attach this to rb2557. > > > > > > > > > > Hopefully Gabe or Alexandru can weigh in. I am happy to help, but I > am at my 'Peter Principal Limit' as far as my understanding goes. > > > > > > > > > > I think it would be really ugly to have a machine-type test to > version the code... > > You should grab a copy of the architecture manual. From there: > > > STAR—The STAR register has the following fields (unless otherwise noted, > all bits are > read/write): > - SYSRET CS and SS Selectors—Bits 63:48. This field is used to specify > both the CS and SS > selectors loaded into CS and SS during SYSRET. If SYSRET is returning to > 32-bit mode > (either legacy or compatibility), this field is copied directly into the > CS selector field. If > SYSRET is returning to 64-bit mode, the CS selector is set to this field + > 16. SS.Sel is set to > this field + 8, regardless of the target mode. Because SYSRET always > returns to CPL 3, the > RPL bits 49:48 should be initialized to 11b. > - SYSCALL CS and SS Selectors—Bits 47:32. This field is used to specify > both the CS and SS > selectors loaded into CS and SS during SYSCALL. This field is copied > directly into CS.Sel. > SS.Sel is set to this field + 8. Because SYSCALL always switches to CPL 0, > the RPL bits > 33:32 should be initialized to 00b. > > > That's why the order matters and is what it is. > > > - Gabe > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2557/#review5782 > ----------------------------------------------------------- > > > On Dec. 10, 2014, 10:11 a.m., Gabe Black wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.gem5.org/r/2557/ > > ----------------------------------------------------------- > > > > (Updated Dec. 10, 2014, 10:11 a.m.) > > > > > > Review request for Default. > > > > > > Repository: gem5 > > > > > > Description > > ------- > > > > Changeset 10606:aa3eb7453246 > > --------------------------- > > x86: kvm: Fix the KVM CPU in SE and FS on Intel CPUs. > > > > There were a number of problems with how things were initialized which > prevent > > VMX from running the simulation as a guest. > > > > > > Diffs > > ----- > > > > src/arch/x86/process.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 > > src/arch/x86/regs/misc.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 > > src/arch/x86/system.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 > > src/arch/x86/system.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 > > src/arch/x86/utility.hh 8fc6e7a835d1d313e139c9095251105f904ac1b4 > > src/arch/x86/utility.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 > > src/cpu/kvm/x86_cpu.cc 8fc6e7a835d1d313e139c9095251105f904ac1b4 > > > > Diff: http://reviews.gem5.org/r/2557/diff/ > > > > > > Testing > > ------- > > > > > > Thanks, > > > > Gabe Black > > > > > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
