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 par
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
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 requi
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.
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 cou
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
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 table,
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 set
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 a
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.
For
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) {
+ pr_err("
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 declares
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
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 c
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 doesn'
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);
>> +
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 currentl
17 matches
Mail list logo