WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

>>> On 28.07.10 at 14:45, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 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.

Who decided that this zapping is going to work on all systems in the
future? E.g. I can't see why a BIOS shouldn't decide to put most of
the ACPI tables in chipset write protected memory, if a chipset offers
such? In such an environment, Dom0 would still see the original
signature - shouldn't we thus correct the original mistake of fiddling
with the ACPI tables as we now have to touch that code anyway?

Jan


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

<Prev in Thread] Current Thread [Next in Thread>