WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH][SVM] CPL initialization fix

To: Robert Phillips <rsp.vi.xen@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][SVM] CPL initialization fix
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 10 Mar 2008 21:57:21 +0000
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>, "Woller, Thomas" <thomas.woller@xxxxxxx>
Delivery-date: Mon, 10 Mar 2008 14:58:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <fc060d960803101301y1f794390q7c1cbfa6d7674a1d@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciC+bcS9ceuP+7sEdyLvQAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH][SVM] CPL initialization fix
User-agent: Microsoft-Entourage/11.4.0.080122
The statement that CPL is directly related to CS.DPL is not true. Conforming
code segments break this relationship, for example. This is despite the fact
that the AMD manual does baldly state at one point that ³When a new selector
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).² 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¹t modify SS.DPL (even though
SYSCALL explicitly does clear SS.DPL).

The assumption that CPL=SS.DPL is used elsewhere in the HVM code. I think
our best bet is to modify hvm_get_segment_register(ss) to force the returned
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" <rsp.vi.xen@xxxxxxxxx> wrote:

> AMD's manual, Vol.2:
> 4.9.2 Privilege-Level Types
> Current Privilege-Level. The current privilege-level (CPL) is the privilege
> level at which the processor is currently executing. The CPL is stored in an
> internal processor register that is invisible to software. Software changes
> the CPL by performing a control transfer to a different code segment with a
> new privilege level.
> 
> So the processor switches CPL by changing code segments, and the CPL is taken
> from the code segment's DPL.
> 
> And what, one might ask, if the stack segment and code segment have different
> DPLs?  The AMD manual doesn't say.  It simply asserts that they will be equal.
> 
> In our experience this is not true.
> 
> 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 guest
> in whatever state we find it.  We found that when the guest happened to be in
> user-mode code (CPL == 3), the migrate failed because, on the receiving node,
> the CPL would be restored to 0. The zero came from SS.DPL.  However the value
> 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.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>