>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
