>>> On 27.08.15 at 11:57, wrote:
> El 27/08/15 a les 11.43, Andrew Cooper ha escrit:
>> On 27/08/15 09:04, Jan Beulich wrote:
>> On 26.08.15 at 16:44, wrote:
El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
> On 26/08/15 13:00, Jan Beulich wrote:
>>> This structure is guaranteed
El 27/08/15 a les 11.43, Andrew Cooper ha escrit:
> On 27/08/15 09:04, Jan Beulich wrote:
> On 26.08.15 at 16:44, wrote:
>>> El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
On 26/08/15 13:00, Jan Beulich wrote:
>> This structure is guaranteed to always be placed in memory after the
On 27/08/15 09:04, Jan Beulich wrote:
On 26.08.15 at 16:44, wrote:
>> El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
>>> On 26/08/15 13:00, Jan Beulich wrote:
> This structure is guaranteed to always be placed in memory after the
DYM "These structures are ..."?
> loaded k
>>> On 26.08.15 at 16:44, wrote:
> El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
>> On 26/08/15 13:00, Jan Beulich wrote:
This structure is guaranteed to always be placed in memory after the
>>> DYM "These structures are ..."?
>>>
loaded kernel and modules.
>>
>> There is no require
El 26/08/15 a les 14.18, Andrew Cooper ha escrit:
> On 26/08/15 12:48, Roger Pau Monné wrote:
>> ELFNOTE(Xen, XEN_ELFNOTE_FEATURES, .asciz,
>> "writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel")
>> ELFNOTE(Xen, XEN_ELFNOTE_SUPPORTED_FEATURES,.long ((1 <<
El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
> On 26/08/15 13:00, Jan Beulich wrote:
>>> This structure is guaranteed to always be placed in memory after the
>> DYM "These structures are ..."?
>>
>>> loaded kernel and modules.
>
> There is no requirement for the command line/module informatio
On 26/08/15 12:48, Roger Pau Monné wrote:
> Hello,
>
> The discussion in [1] lead to an agreement of the missing pieces in PVH
> (or HVM without a device-model) in order to progress with it's
> implementation.
>
> One of the missing pieces is a new boot ABI, that replaces the PV boot
> ABI. The aim
On 26/08/15 13:00, Jan Beulich wrote:
>
>> struct hvm_start_info {
>> #define HVM_START_MAGIC_VALUE 0x336ec578
>> uint32_t magic; /* Contains the magic value 0x336ec578
>> */
>> /* ("xEn3" with the 0x80 bit of the "E"
>> set).*/
>> uint32_
>>> On 26.08.15 at 13:48, wrote:
> * tr: must be a 32-bit TSS (active) with a base of '0' and a limit of '0xFF'.
Why 0xFF instead of 0x67?
> struct hvm_start_info {
> #define HVM_START_MAGIC_VALUE 0x336ec578
> uint32_t magic; /* Contains the magic value 0x336ec578
> */
>
Hello,
The discussion in [1] lead to an agreement of the missing pieces in PVH
(or HVM without a device-model) in order to progress with it's
implementation.
One of the missing pieces is a new boot ABI, that replaces the PV boot
ABI. The aim of this new boot ABI is to remove the limitations of th
10 matches
Mail list logo