lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <46A66D12.1080804@goop.org>
Date:	Tue, 24 Jul 2007 14:20:18 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Tilman Schmidt <tilman@...p.cc>
CC:	Andi Kleen <andi@...stfloor.org>, Olaf Hering <olh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Gabriel C <nix.or.die@...glemail.com>
Subject: Re: 2.6.22-git17 boot failure

Tilman Schmidt wrote:
> Apparently not, given that the generated init script is mistaking
> a native environment for a domU instead of a dom0.
>
> In fact, when running 2.6.23-rc1 natively, no matter if compiled
> with or without Xen support, the directory /proc/xen doesn't even
> exist:
>   

No, the in-tree Xen stuff doesn't do anything with /proc/xen, and I
don't think I'll try to merge anything that does.

> OTOH, the Opensuse Xen kernel vmlinuz-2.6.18.8-0.5-xen cannot even
> be booted natively because GRUB complains immediately:
>   Error 13: Invalid or unsupported executable format
> Conversely, the Xen loader flatly refuses to load a self-compiled,
> Xen enabled 2.6.23-rc1 kernel as dom0, complaining:
>   DOM0 image is not an Xen-compatible Elf image.
> So I guess the point is moot, because you cannot use the same image
> as dom0 and natively, anyway.
>   

No, but a dom0 kernel should look like a normal kernel from all the
device's perspective, with the added ability to fire up other domains. 
When I get around to adding dom0 support to the pvops kernel, this will
all get even more fluid.

The simple answer is that if you want to test if you can probe PCI/load
PCI device drivers, you should just go ahead and try; it will either
work or not.  No point testing something unrelated to see if you can.

The OpenSUSE init script is making the now-invalid assumption that you
can't have a CONFIG_XEN kernel that can talk to devices which isn't also
dom0.  It needs to have its horizons broadened.

    J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ