linux-kernel - Re: [RFC v1 4/8] x86/init: add linker table support

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: <CAB=NE6WwRd963i60-zoi-_EwGPJKDtOkmBtvM_8usALr9NRUqw@mail.gmail.com>
Date:	Thu, 11 Feb 2016 12:45:19 -0800
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Takashi Iwai <tiwai@...e.de>, Avi Kivity <avi@...hat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Roger Pau Monné <roger.pau@...rix.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andy Lutomirski <luto@...capital.net>,
	Michael Brown <mcb30@...e.org>,
	Juergen Gross <jgross@...e.com>,
	Jan Beulich <JBeulich@...e.com>,
	Joerg Roedel <joro@...tes.org>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	long.wanglong@...wei.com, qiuxishi@...wei.com,
	aryabinin@...tuozzo.com,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Valentin Rothberg <valentinrothberg@...il.com>,
	Peter Senna Tschudin <peter.senna@...il.com>,
	X86 ML <x86@...nel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v1 4/8] x86/init: add linker table support

On Thu, Jan 21, 2016 at 4:42 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 01/21/16 16:25, Luis R. Rodriguez wrote:
>>>
>>> Basically, if the hardware is enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need a special boot flow it should use type 0.
>>
>> I can extend the documentation as part of this to be clear.
>>
>> I will note though that this still leaves a gap on code which might
>> want to access the question "are we in a virt environment, and if so
>> on which one" in between really early boot and right before
>> init_hypervisor_platform(). Or rather, given subarch can be used by
>> Xen and lguest but not KVM it means KVM doesn't get to use it. It may
>> not need it, but its also rather trivial to set up on qemu, and I have
>> a patch for that if we wanted one for KVM. That would extend the
>> definition of subarch a bit more, but as it stands today its use was
>> rather limited. Heck, subharch_data is to this day unused.
>>
>
> KVM is not a subarch, and Xen HVM isn't either; the subarch was meant to
> be specifically to handle nonstandard boot entries; the CE4100 extension
> was itself kind of a hack.
>
> If you have a genuine need for a "hypervisor type" then that is a
> separate thing and should be treated separately from subarch.  However,
> you need to consider that some hypervisors can emulate other hypervisors
> and you may have more than one hypervisor API available.

Thanks, I've pegged this onto my series as a documentation extensions
for boot params.

 Luis