From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH][SVM] CPL initialization fix Date: Mon, 10 Mar 2008 21:57:21 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Robert Phillips Cc: xen-devel , Ben Guthro , "Woller, Thomas" List-Id: xen-devel@lists.xenproject.org The statement that CPL is directly related to CS.DPL is not true. Conformin= g code segments break this relationship, for example. This is despite the fac= t that the AMD manual does baldly state at one point that =B3When a new selecto= r is loaded into the CS register, the current-privilege level (CPL) of the processor is set to that of the CS-segment descriptor-privilege level (DPL).=B2 Conforming code segments clearly break this, unless AMD differ from Intel and nobble CS.DPL in this case, but if they do it's not mentioned in the manuals. It looks to me as though AMD maintains CPL separately from SS.DPL because they explicitly define that SYSRET doesn=B9t modify SS.DPL (even though SYSCALL explicitly does clear SS.DPL). The assumption that CPL=3DSS.DPL is used elsewhere in the HVM code. I think our best bet is to modify hvm_get_segment_register(ss) to force the returne= d dpl to vmcb->cpl. Then get/set are symmetric, other ss.dpl checks in hvm code will work, and save/restore also is fixed. I've cc'ed Tom Woller in case he can clarify further. -- Keir On 10/3/08 20:01, "Robert Phillips" wrote: > AMD's manual, Vol.2: > 4.9.2 Privilege-Level Types > Current Privilege-Level. The current privilege-level (CPL) is the privile= ge > level at which the processor is currently executing. The CPL is stored in= an > internal processor register that is invisible to software. Software chang= es > the CPL by performing a control transfer to a different code segment with= a > new privilege level. >=20 > So the processor switches CPL by changing code segments, and the CPL is t= aken > from the code segment's DPL. >=20 > And what, one might ask, if the stack segment and code segment have diffe= rent > DPLs? The AMD manual doesn't say. It simply asserts that they will be e= qual. >=20 > In our experience this is not true. >=20 > When we perform a live migrate from a HVM VS without PV drivers [what Ben > Guthro referred to as a QEMU-only virtual server], we simply pause the gu= est > in whatever state we find it. We found that when the guest happened to b= e in > user-mode code (CPL =3D=3D 3), the migrate failed because, on the receiving n= ode, > the CPL would be restored to 0. The zero came from SS.DPL. However the v= alue > in CS.DPL was 3. > SS.DPL was not equal to CS.DPL. > When we changed the code (per this patch), the CPL would be restored from > CS.DPL. That value was correct in all cases.