Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1332357 > unrolled thread
| Started by | "Luis R. Rodriguez" <mcgrof@do-not-panic.com> |
|---|---|
| First post | 2016-02-11 21:50 +0100 |
| Last post | 2016-02-11 21:50 +0100 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [RFC v1 4/8] x86/init: add linker table support "Luis R. Rodriguez" <mcgrof@do-not-panic.com> - 2016-02-11 21:50 +0100
| From | "Luis R. Rodriguez" <mcgrof@do-not-panic.com> |
|---|---|
| Date | 2016-02-11 21:50 +0100 |
| Subject | Re: [RFC v1 4/8] x86/init: add linker table support |
| Message-ID | <r16lA-5v2-15@gated-at.bofh.it> |
On Thu, Jan 21, 2016 at 4:42 PM, H. Peter Anvin <hpa@zytor.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
Back to top | Article view | linux.kernel
csiph-web