On 12/12/2017 09:06, Jan Beulich wrote:
On 11.12.17 at 22:59, wrote:
>> On 08/12/2017 09:49, Jan Beulich wrote:
+ * The layout of each entry in the memory map table is as follows and no
+ * padding is used between entries in the array:
+ *
+ * 0 ++
+
>>> On 11.12.17 at 22:59, wrote:
> On 08/12/2017 09:49, Jan Beulich wrote:
>>> + * The layout of each entry in the memory map table is as follows and no
>>> + * padding is used between entries in the array:
>>> + *
>>> + * 0 ++
>>> + *| addr | Base address
>>> + * 8
On 08/12/2017 09:49, Jan Beulich wrote:
>> + * The layout of each entry in the memory map table is as follows and no
>> + * padding is used between entries in the array:
>> + *
>> + * 0 ++
>> + *| addr | Base address
>> + * 8 ++
>> + *| size
>>> On 08.12.17 at 20:05, wrote:
> On 12/8/2017 12:49 AM, Jan Beulich wrote:
>> I'm not convinced of re-using E820 types here. I can see that this
>> might ease the consumption in Linux, but I don't think there should
>> be any connection to x86 aspects here - the data being supplied is
>> x86-agn
Thanks for taking a look Jan. More below...
On 12/8/2017 12:49 AM, Jan Beulich wrote:
On 07.12.17 at 23:45, wrote:
The start info structure that is defined as part of the x86/HVM direct
boot ABI and used for starting Xen PVH guests would be more versatile if
it also included a way to efficient
>>> On 07.12.17 at 23:45, wrote:
> The start info structure that is defined as part of the x86/HVM direct
> boot ABI and used for starting Xen PVH guests would be more versatile if
> it also included a way to efficiently pass information about the memory
> map to the guest.
>
> That way Xen PVH g
The start info structure that is defined as part of the x86/HVM direct
boot ABI and used for starting Xen PVH guests would be more versatile if
it also included a way to efficiently pass information about the memory
map to the guest.
That way Xen PVH guests would not be forced to use a hypercall t
7 matches
Mail list logo