From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v3 07/32] xen/x86: fix arch_set_info_guest for HVM guests Date: Wed, 5 Aug 2015 20:00:29 +0100 Message-ID: <55C25D4D.2090606@citrix.com> References: <1435923310-9019-1-git-send-email-roger.pau@citrix.com> <1437651718.19412.92.camel@citrix.com> <55B103DD.4030901@citrix.com> <55B125440200007800094BD2@prv-mh.provo.novell.com> <55B10CDB.5010708@citrix.com> <1437667259.24746.12.camel@citrix.com> <55B11316.2000201@citrix.com> <55B130420200007800094CB8@prv-mh.provo.novell.com> <55B11CBE.8050704@citrix.com> <55B1208C.9090207@citrix.com> <55B211D70200007800094FCF@prv-mh.provo.novell.com> <55B20C9D.5070708@citrix.com> <55B233890200007800095124@prv-mh.provo.novell.com> <55B22B5A.8020304@citrix.com> <55B24F4A02000078000952CC@prv-mh.provo.novell.com> <55B25941.9@citrix.com> <55B27AAB02000078000954A0@prv-mh.provo.novell.com> <55B26DB1.4020302@citrix.com> <55BF9CE6.1030904@citrix.com> <55BFA569.7050102@citrix.com> <55C0FF93.70501@citrix.com> <55C1DD1C.3060108@citrix.com> <55C22E1C.5020703@citrix.com> <55C23C6E.9010300@citrix.com> <55C23DD5.3030702@citrix.com> <55C243B5.50406@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZN3w7-0007jd-Ke for xen-devel@lists.xenproject.org; Wed, 05 Aug 2015 19:01:11 +0000 In-Reply-To: <55C243B5.50406@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: =?windows-1252?Q?Roger_Pau_Monn=E9?= , Jan Beulich Cc: xen-devel@lists.xenproject.org, Boris Ostrovsky , David Vrabel , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 05/08/15 18:11, Roger Pau Monn=E9 wrote: > El 05/08/15 a les 18.46, Andrew Cooper ha escrit: >> On 05/08/15 17:40, Roger Pau Monn=E9 wrote: >>> El 05/08/15 a les 17.39, Andrew Cooper ha escrit: >>>> On 05/08/15 10:53, Roger Pau Monn=E9 wrote: >>>>> El 04/08/15 a les 20.08, Andrew Cooper ha escrit: >>>>>> On 03/08/15 18:31, Roger Pau Monn=E9 wrote: >>>>>>> uint32_t cs_base; >>>>>>> uint32_t ds_base; >>>>>>> uint32_t ss_base; >>>>>>> uint32_t cs_limit; >>>>>>> uint32_t ds_limit; >>>>>>> uint32_t ss_limit; >>>>>>> uint16_t cs_ar; >>>>>>> uint16_t ds_ar; >>>>>>> uint16_t ss_ar; >>>>>> You need selector entries for each segment as well. >>>>> Really? What's the point in having the selector if we don't have a GD= T, >>>>> and we allow loading the cached part, which is the relevant one. >>>> push %cs; push 1f; lret >>>> >>>> At all points when segment details are updated, it is the responsibili= ty >>>> of software to ensure that the details match with the GDT/LDT entry. = >>>> See for example the Intel and AMD manuals for syscall/sysenter where >>>> similar "updating segment details behind the scenes" occurs. >>> I would certainly expect the user to have loaded a proper GDT and >>> reloaded the segments selectors before attempting to do something like >>> the above. >>> >>> I really don't mind adding a cs_sel, ds_sel, ss_sel and tr_sel, I just >>> think it's quite pointless because it's common practice to load a GDT >>> and then reload the segment selectors to point to the right entries. >> Consider what would happen if the vcpu hits mmio and bounces into Xen >> for emulation before reloading the segment selectors. > I hope Xen is just going to kill the guest. I would hope for it to work properly. > >> The segment selector information needs to be consistent, as it might not >> be the guest which is the next entity to observe the vcpu state. > I guess I'm missing something, but AFAICT we already start the BSP in > such "inconsistent" state, So we do. (There are a number of inconsistencies in that area.) > the cached part of the selectors is right but > the selectors themselves don't point to valid GDT entries because > there's no GDT loaded. Hmm yes - you are correct. On native, the cached part of the segment selectors only get updated with a segment selector is loaded, at which point the gdt/ldt must be valid. However there is no requirement or need for the gdt/ldt to stay valid after the cached part has been loaded. Unreal mode relies on this. Considering that the first thing any AP startup function will do is lgdt and reload the segment registers, we can do without maintaining selector consistency. Sorry for the confusion. ~Andrew