From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wang, Shane" Subject: RE: [PATCH] to fix the bug for tboot on x86_32 brought by c/s 19914 and 19922 Date: Mon, 9 Nov 2009 10:55:56 +0800 Message-ID: <037F493892196B458CD3E193E8EBAD4F01EEBAF249@pdsmsx502.ccr.corp.intel.com> References: <4AF408A1.9060600@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , "xen-devel@lists.xensource.com" , "Cihula, Joseph" , "Hao, Xudong" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 06/11/2009 11:29, "Shane Wang" wrote: >=20 >> The changesets 19914 and 19922 remove the bitmap for boot allocator, >> which causes first_valid_mfn is reduced and starts from the end of >> xen. On the other hand, on x86_64, the xen heap is got considering >> e820 table, while on x86_32 the xen heap is specified to be < >> xenheap_phys_end. This range overlaps tboot range. So, the tboot >> range is scrubbed by scrub_heap_pages() during start_xen() on >> x86_32. Then the result is that for TXT support on x86_32, >> shutdown/reboot/Sx doesn't work properly. (i.e. hang)=20 >=20 > So... The problem is that xenheap on x86_32 does not respect e820? > I'll fix that if that's the issue. It will be a much smaller change, > and to arch/x86/setup.c only. Yes, it is. It seems x86_32 only respects after xenheap is created. >=20 > -- Keir >=20 >> This patch is to fix that by reserving tboot range as "inuse" in xen >> heap on x86_32. Then xen code will not touch the range.