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

On Thu, Jan 21, 2016 at 4:42 PM, H. Peter Anvin 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

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

On Thu, Jan 21, 2016 at 4:42 PM, H. Peter Anvin 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

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

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

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

On Wed, Jan 20, 2016 at 2:20 PM, H. Peter Anvin wrote: > On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez" > wrote: >>On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote: >>> On 01/20/16 13:33, Luis R. Rodriguez wrote: That's correct for PV and PVH, likewise when qemu is

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

On Thu, Jan 21, 2016 at 11:52 AM, H. Peter Anvin wrote: > On 01/21/16 11:50, H. Peter Anvin wrote: >> >> Right... we already do that. >> >> I don't even think you need to initialize any tables. At least on i386, >> we have to do this in assembly code. However, it is just a simple table >> walk.

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

On 01/21/16 12:05, Luis R. Rodriguez wrote: > >> At least on i386, >> we have to do this in assembly code. > > Neat! How is that order kept? > Right now subarch_entries[] is just an array indexed by subarch number hardcoded in head_32.S. However, if you have a list of (id, target) then you

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

On Thu, Jan 21, 2016 at 11:50 AM, H. Peter Anvin wrote: >> The PV init code would kick in early and could parse the >> boot_params.hdr.hardware_subarch_data pointer as it sees fit. >> > > Right... we already do that. > > I don't even think you need to initialize any tables. The init above is for

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

On 01/21/16 11:50, H. Peter Anvin wrote: > > Right... we already do that. > > I don't even think you need to initialize any tables. At least on i386, > we have to do this in assembly code. However, it is just a simple table > walk. :) > It might make more sense to make subarch its own

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

On 01/21/16 11:46, Luis R. Rodriguez wrote: > On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin wrote: >>> And that's exactly what HVMlite does. Most of this shim layer is setting >>> up boot_params, after which we jump to standard x86 boot path (i.e. >>> startup_{32|64}). With hardware_subarch

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

On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin wrote: >> And that's exactly what HVMlite does. Most of this shim layer is setting >> up boot_params, after which we jump to standard x86 boot path (i.e. >> startup_{32|64}). With hardware_subarch set to zero. > > Which is the way to do it as long

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

On 01/21/16 05:45, Boris Ostrovsky wrote: >> I don't think the hypervisor should be setting Linux specific boot >> related parameters, the boot ABI should be OS agnostic. IMHO, a small >> shim should be added to Linux in order to set what Linux requires when >> entering from a Xen entry point.

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

On 01/21/2016 03:38 AM, Roger Pau Monné wrote: El 20/01/16 a les 22.33, Luis R. Rodriguez ha escrit: On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk wrote: +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn) +{ + if (!fn->supp_hardware_subarch) { +

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

El 20/01/16 a les 22.33, Luis R. Rodriguez ha escrit: > On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk > wrote: >>> +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn) >>> +{ >>> + if (!fn->supp_hardware_subarch) { >>> + pr_err("Init sequence fails to

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

On 01/21/2016 03:38 AM, Roger Pau Monné wrote: El 20/01/16 a les 22.33, Luis R. Rodriguez ha escrit: On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk wrote: +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn) +{ + if (!fn->supp_hardware_subarch)

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

El 20/01/16 a les 22.33, Luis R. Rodriguez ha escrit: > On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk > wrote: >>> +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn) >>> +{ >>> + if (!fn->supp_hardware_subarch) { >>> + pr_err("Init

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

On 01/21/16 05:45, Boris Ostrovsky wrote: >> I don't think the hypervisor should be setting Linux specific boot >> related parameters, the boot ABI should be OS agnostic. IMHO, a small >> shim should be added to Linux in order to set what Linux requires when >> entering from a Xen entry point.

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

On Thu, Jan 21, 2016 at 11:50 AM, H. Peter Anvin wrote: >> The PV init code would kick in early and could parse the >> boot_params.hdr.hardware_subarch_data pointer as it sees fit. >> > > Right... we already do that. > > I don't even think you need to initialize any tables. The

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

On 01/21/16 12:05, Luis R. Rodriguez wrote: > >> At least on i386, >> we have to do this in assembly code. > > Neat! How is that order kept? > Right now subarch_entries[] is just an array indexed by subarch number hardcoded in head_32.S. However, if you have a list of (id, target) then you

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

On Thu, Jan 21, 2016 at 11:52 AM, H. Peter Anvin wrote: > On 01/21/16 11:50, H. Peter Anvin wrote: >> >> Right... we already do that. >> >> I don't even think you need to initialize any tables. At least on i386, >> we have to do this in assembly code. However, it is just a

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

On Wed, Jan 20, 2016 at 2:20 PM, H. Peter Anvin wrote: > On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez" > wrote: >>On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote: >>> On 01/20/16 13:33, Luis R. Rodriguez wrote:

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

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

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

On 01/21/16 11:50, H. Peter Anvin wrote: > > Right... we already do that. > > I don't even think you need to initialize any tables. At least on i386, > we have to do this in assembly code. However, it is just a simple table > walk. :) > It might make more sense to make subarch its own

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

On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin wrote: >> And that's exactly what HVMlite does. Most of this shim layer is setting >> up boot_params, after which we jump to standard x86 boot path (i.e. >> startup_{32|64}). With hardware_subarch set to zero. > > Which is the way

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

On 01/21/16 11:46, Luis R. Rodriguez wrote: > On Thu, Jan 21, 2016 at 11:25 AM, H. Peter Anvin wrote: >>> And that's exactly what HVMlite does. Most of this shim layer is setting >>> up boot_params, after which we jump to standard x86 boot path (i.e. >>> startup_{32|64}). With

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

On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez" wrote: >On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote: >> On 01/20/16 13:33, Luis R. Rodriguez wrote: >>> >>> That's correct for PV and PVH, likewise when qemu is required for >HVM >>> qemu could set it. I have the qemu change done

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

On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote: > On 01/20/16 13:33, Luis R. Rodriguez wrote: >> >> That's correct for PV and PVH, likewise when qemu is required for HVM >> qemu could set it. I have the qemu change done but that should only >> cover HVM. A common place to set this as well

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

On 01/20/16 13:33, Luis R. Rodriguez wrote: > > That's correct for PV and PVH, likewise when qemu is required for HVM > qemu could set it. I have the qemu change done but that should only > cover HVM. A common place to set this as well could be the hypervisor, > but currently the hypervisor

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

On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk wrote: >> +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn) >> +{ >> + if (!fn->supp_hardware_subarch) { >> + pr_err("Init sequence fails to declares any supported >> subarchs: %pF\n", fn->early_init); >> +

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

On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk wrote: >> +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn) >> +{ >> + if (!fn->supp_hardware_subarch) { >> + pr_err("Init sequence fails to declares any supported >> subarchs: %pF\n",

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

On 01/20/16 13:33, Luis R. Rodriguez wrote: > > That's correct for PV and PVH, likewise when qemu is required for HVM > qemu could set it. I have the qemu change done but that should only > cover HVM. A common place to set this as well could be the hypervisor, > but currently the hypervisor

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

On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote: > On 01/20/16 13:33, Luis R. Rodriguez wrote: >> >> That's correct for PV and PVH, likewise when qemu is required for HVM >> qemu could set it. I have the qemu change done but that should only >> cover HVM. A common place to

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

On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez" wrote: >On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote: >> On 01/20/16 13:33, Luis R. Rodriguez wrote: >>> >>> That's correct for PV and PVH, likewise when qemu is required for >HVM >>> qemu

[RFC v1 4/8] x86/init: add linker table support

From: "Luis R. Rodriguez" Any failure on the x86 init path can be catastrophic. A simple shift of a call from one place to another can easily break things. Likewise adding a new call to one path without considering all x86 requirements can make certain x86 run time environments crash. We

[RFC v1 4/8] x86/init: add linker table support

From: "Luis R. Rodriguez" Any failure on the x86 init path can be catastrophic. A simple shift of a call from one place to another can easily break things. Likewise adding a new call to one path without considering all x86 requirements can make certain x86 run time environments