Vivek Goyal <[EMAIL PROTECTED]> writes:

> On Thu, Oct 12, 2006 at 06:47:08PM +0900, Magnus Damm wrote:
>> Hi Vivek,
>> 
>> This patch breaks kdump under Xen/dom0. This is because "Kernel code"
>> isn't listed in /proc/iomem. The reason behind this is probably that
>> the address where the kernel is loaded is in pseudo physical address
>> space, and this space is not contiguously mapped 1:1 to machine
>> addresses (real physical addresses in the Linux world).
>> 
>> If we really want to pass physical addresses under Xen we need to pass
>> the address of each and every page that maps the kernel. This sounds
>> like a pretty redundant move IMO because the tool that parses Xen
>> crash dumps needs to be (and is already) aware of this mapping anyhow.
>> 
>> So the following (mangled) patch fixes this by warning instead of
>> returning error:
>> 
>
> Magnus, I think this patch is problematic. This bypasses the
> error checking mechanism in non-virtualized env. So due to some reason if
> "Kernel Code" is not exported from /proc/iomem, kexec-tools will never
> detect it and set the phyaddr to zero. And a kernel header will be created
> with kernel virtual address X pointing to physical addr 0 which is wrong.
> It should have been kernel virtual addr X pointing to physical addr 2MB
> (Assuming kernel is loaded physically at 2MB addr).
>
> I think somehow we shall have to make kexec-tools Xen aware to take care
> of Xen special cases.

Agreed.  If we are running in a mode that is not fully virtualized anything
running directly in that mode needs to understand that.  Therefore kexec
needs to understand that.

If we understand we are running in a different mode we can take
appropriate action. 

Eric


_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot

Reply via email to