[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] ACPI-Tables corrupted?


  • To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Wed, 28 Jul 2010 15:27:54 +0200
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 28 Jul 2010 06:28:41 -0700
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CrztTxxTy+7WB6yTT/bVD5qo4+ypGu7HV6aA2mN6TIb+Uxj8HsmNa7N0 OAjsisnAb2vMaZcv9v5eJHOIvqUz3615YBpzsW9VB157zZY+WJLsKd6zd rasD9oaCPyPO5RANfScFGBw9BIwcU3ugTaGyM9dPJ15sJxbqjgL3mkp8A llqRSW/yLNlwoRKMeA75jn5hLUup2rAQwkUT+k6R+HbNzda3b+qFjEB5F Xldr5jJTPRvG6Om6Hj6yHKV1TRavE;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 07/28/2010 02:45 PM, Keir Fraser wrote:
On 28/07/2010 13:13, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx>  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@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.