This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] ACPI-Tables corrupted?
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 28 Jul 2010 13:45:12 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 28 Jul 2010 05:46:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C501EF3.8070402@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcsuTlGd3tLqa7fmSe21fvAmRDs8nwABGZu0
Thread-topic: [Xen-devel] ACPI-Tables corrupted?
User-agent: Microsoft-Entourage/
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 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.

 -- Keir

>                  /*
>                   * without IR all CPUs can be addressed by IOAPIC/MSI
>                   * only in physical mode
>                   */
>                  x2apic_force_phys();
>          }
>          x2apic_enabled = 1;
>          if (x2apic_supported() && !x2apic_mode) {
>                  x2apic_mode = 1;
>                  enable_x2apic();
>                  pr_info("Enabled x2apic\n");
>          }
> nox2apic:
>          if (!ret) /* IR enabling failed */
>                  restore_IO_APIC_setup(ioapic_entries);
>          unmask_8259A();
>          local_irq_restore(flags);
> out:
>          if (ioapic_entries)
>                  free_ioapic_entries(ioapic_entries);
>          if (x2apic_enabled)
>                  return;
>          if (x2apic_preenabled)
>                  panic("x2apic: enabled by BIOS but kernel init failed.");
>          else if (cpu_has_x2apic)
>                  pr_info("Not enabling x2apic, Intr-remapping init
> failed.\n");
> }
> dmar_table_init() will return -ENODEV if no DMAR record is found.
> Juergen

Xen-devel mailing list