From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: Real-mode bug with AMD, gPXE, and 32-bit rep movs Date: Thu, 26 Mar 2009 17:24:06 +0100 Message-ID: <200903261724.06593.Christoph.Egger@amd.com> References: <49CB9BFA.50408@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49CB9BFA.50408@eu.citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: George Dunlap , "Huang2, Wei" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Thursday 26 March 2009 16:15:06 George Dunlap wrote: > Keir Fraser wrote: > > On 26/03/2009 12:25, "George Dunlap" wrote: > >> There are three possibilities I came up with: > >> 1) The same thing would happen outside of SVM; in which case it's > >> (sort of) a gPXE bug for using an instruction that won't work on AMD > >> boxes. > >> 2) Xen is subtly screwing up the VM state, causing the AMD hardware > >> not to recognize that this shouldn't cause a #GP I think it's #2. Look at the #GP causes in APM Volume 2 for MOVSx: the only one in real mode is if the address exceeded a data segment limit. And the comment from Deegan about clipping segment limits to 16 bits makes me think that the clipping is happening on AMD machines and it shouldn't be. So probably, VMCB.DS.LIMIT is smaller than it should be. Note, that AMD requires the segment limit to be the effective limit and the granularity segment attribute is ignored. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632