From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: ACPI-Tables corrupted? Date: Wed, 28 Jul 2010 15:27:54 +0200 Message-ID: <4C50305A.8070209@ts.fujitsu.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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 Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 07/28/2010 02:45 PM, Keir Fraser wrote: > On 28/07/2010 13:13, "Juergen Gross" wrote: > >>>> As Dom0 is a pv-kernel, it should be able to ignore this entry. >>>> The crash kernel OTOH should not panic due to the trashed entry! >>>> What is the correct solution here? >>> >>> Could provide a cmdline option to not nobble the DMAR? >> >> That's a possibility. >> I wonder whether it wouldn't be better to let dom0 decide not to use it if >> running under xen. This would remove the requirement for zapping the ACPI >> table. IMO it's always a bad idea to change data of a deeper layer... > > If we don't zap the DMAR then every existing dom0 kernel will fail with new > hypervisor. We could gate it on a new elfnote, or rename to XMAR and have > dom0 rename it back, or just have a flag day. The really clean solution would be to virtualize the ACPI table for dom0 and remove the DMAR entry in this version. This would require some major work, I guess (clone at least the BIOS page containing the ACPI anchor and present a modified version to dom0). > >>>> The crash kernel expects a valid DMAR entry, as following code in >>>> enable_IR_x2apic() suggests: >>> >>> I don't know what that function does, nor how the error path below depends >>> on DMAR. DMAR isn't mentioned in the below code. >> >> Sorry, here a larger fragment (source arch/x86/kernel/apic/apic.c): >> /* IR is required if there is APIC ID> 255 even when running >> * under KVM >> */ >> if (max_physical_apicid> 255 || !kvm_para_available()) >> goto nox2apic; > > The if stmt is confusing. Also, what would happen if this kernel was booted > on a system without VT-d (and hence no DMAR)? Presumably it *can* boot in a > DMAR-less environment -- there must be something odd going on for it to end > on this path for us. Yeah, that puzzled me, too. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html