From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Subject: Re: [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs Date: Wed, 30 Sep 2015 17:33:45 +0200 Message-ID: <560C00D9.7030603@citrix.com> References: <1441368548-43465-1-git-send-email-roger.pau@citrix.com> <1441368548-43465-25-git-send-email-roger.pau@citrix.com> <5600420C02000078000A4234@prv-mh.provo.novell.com> <5609664D.8060604@citrix.com> <560A555402000078000A6625@prv-mh.provo.novell.com> <560A6124.2090404@citrix.com> <560A7EFA02000078000A6846@prv-mh.provo.novell.com> <560A6714.7060303@citrix.com> <560A851202000078000A68AA@prv-mh.provo.novell.com> <560A69DB.9060505@citrix.com> <560A888D02000078000A68DD@prv-mh.provo.novell.com> <560A99C0.5050202@citrix.com> <560ACA7302000078000A6C93@prv-mh.provo.novell.com> <560AB5C6.6080404@citrix.com> <560AD65F02000078000A6CF6@prv-mh.provo.novell.com> <560AC129.1040309@citrix.com> <560BCF9102000078000A7016@prv-mh.provo.novell.com> <560BC970.1060300@citrix.com> <560BE9A502000078000A716C@prv-mh.provo.novell.com> <560BD345.5090301@citrix.com> <560BF31D02000078000A71BF@prv-mh.provo.novell.com> <560BDAB3.70701@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZhJOB-0007SF-K5 for xen-devel@lists.xenproject.org; Wed, 30 Sep 2015 15:33:51 +0000 In-Reply-To: <560BDAB3.70701@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Jan Beulich Cc: George Dunlap , xen-devel@lists.xenproject.org, Stefano Stabellini , Ian Campbell , Tim Deegan List-Id: xen-devel@lists.xenproject.org El 30/09/15 a les 14.50, Andrew Cooper ha escrit: > On 30/09/15 13:35, Jan Beulich wrote: >>>>> On 30.09.15 at 14:19, wrote: >>> El 30/09/15 a les 13.54, Jan Beulich ha escrit: >>>>>>> On 30.09.15 at 13:37, wrote: >>>>> /* >>>>> * Using VCPU_HVM_MODE_64B implies that the vCPU is launched >>>>> * directly in long mode, so the type of the cached part >>>>> * of the TR register is set to describe a 64-bit TSS (Busy). >>>>> * The cached part of the CS register will also have the L bit >>>>> * set (64-bit code segment). >>>> I'd leave out mentioning TR here (or else it'll be odd not to mention >>>> e.g. LDTR too). Perhaps just "..., so the cached parts of the segment >>>> registers get set to match that environment"? >>> That sounds fine. I'm going to update the patch and the FreeBSD part in >>> order to test it. Since we also spoke about adding sanity checks, I >>> wonder whether I should add those checks now, or leave them for a later >>> patch. IMHO those checks are only useful for developers. >> Fundamentally, checks done here should include everything that >> would otherwise lead to the domain getting killed due to failed >> VMENTRY. I.e. both sets below may need extending. >> >>> For VCPU_HVM_MODE_32B: >>> - rIP within CS limit. >>> - Check that CS.DPL == SS.DPL. >>> - rSP within SS limit. >>> >>> TBH I don't think we should enforce the last two checks, starting with >>> an invalid stack should be fine as long as the user knows it. Maybe >>> print a warning/debug message in this case? >> I wouldn't check ESP at all. As to the two DPLs to, I don't think you >> could launch a guest with these disagreeing. >> >>> For VCPU_HVM_MODE_64B: >>> - Check that cr0 has paging enabled. >>> - Check that cr4 has pae enabled. >>> - Check that efer has the LMA/LME bits set. >>> >>> Those should be always enforced for long mode. >> Agreed, plus RIP being canonical. > > LMA is a read-only bit with inconsistent semantics between Intel and AMD. > > In particular, on Intel, LMA is not visible until LME has been set, > which means that the typical setup of > > mov $MSR_EFER, %ecx > rdmsr > bts $_EFER_LME, %eax > wrmsr > > Causes Xen to observe LME but not LMA when intercepting the wrmsr. > > I think all you need to check is CR0.PG, CR4.PAE and EFER.LME (and guest > X86_FEATURE_LM). LMA will then leak through in subsequent rdmsr's Although you don't need to set LMA in real hardware, AFAICT you need to set it when using this interface, because hvm_update_guest_efer doesn't set LMA if LME is enabled, which causes the vmentry to fail. Roger.