On Thu, Jun 11, 2015 at 08:18:27AM +0100, Jan Beulich wrote:
> >>> On 10.06.15 at 20:55, wrote:
> > On Wed, Jun 10, 2015 at 02:34:00PM +0200, Roger Pau Monné wrote:
> >> The first three notes contain information about the guest kernel and
> >> the Xen hypercall ABI version. The following notes ar
On Thu, Jun 11, 2015 at 10:43:08AM +0200, Roger Pau Monné wrote:
> El 10/06/15 a les 20.55, Konrad Rzeszutek Wilk ha escrit:
> > On Wed, Jun 10, 2015 at 02:34:00PM +0200, Roger Pau Monné wrote:
> >> Hello,
> >>
> >> The discussion in [1] lead to an agreement of the missing pieces in PVH
> >> (or H
At 14:15 +0100 on 10 Jun (1433945712), Jan Beulich wrote:
> >>> On 10.06.15 at 14:34, wrote:
> > * XEN_ELFNOTE_PADDR_OFFSET: the offset of the ELF paddr field from the
> >actual required physical address.
>
> Why would that be needed? I.e. why would there ever be an offset?
I had the same q
El 10/06/15 a les 20.55, Konrad Rzeszutek Wilk ha escrit:
> On Wed, Jun 10, 2015 at 02:34:00PM +0200, 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.
El 10/06/15 a les 23.31, Andrew Cooper ha escrit:
> On 10/06/2015 19:55, Konrad Rzeszutek Wilk wrote:
>>> All other processor registers and flag bits are undefined. The OS is in
>>> charge of setting up it's own stack, GDT and IDT.
>>>
>>> Note that the boot protocol resembles the multiboot1 speci
El 10/06/15 a les 17.57, Andrew Cooper ha escrit:
Do we want to keep using the start_info page? Most of the fields there
are not relevant for auto-translated guests, but without it we have to
figure out how to pass the following information to the guest:
- Flags: SIF_xxx
>>> On 10.06.15 at 20:55, wrote:
> On Wed, Jun 10, 2015 at 02:34:00PM +0200, Roger Pau Monné wrote:
>> The first three notes contain information about the guest kernel and
>> the Xen hypercall ABI version. The following notes are of special
>> interest:
>>
>> * XEN_ELFNOTE_PADDR_OFFSET: the of
On 10/06/2015 19:55, Konrad Rzeszutek Wilk wrote:
>> All other processor registers and flag bits are undefined. The OS is in
>> charge of setting up it's own stack, GDT and IDT.
>>
>> Note that the boot protocol resembles the multiboot1 specification,
>> this is done so OSes with multiboot1 entry
On Wed, Jun 10, 2015 at 02:34:00PM +0200, 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
On 10/06/15 16:38, Roger Pau Monné wrote:
> El 10/06/15 a les 15.18, Andrew Cooper ha escrit:
>>> * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits
>>>are all undefined.
>> "unspecified" is perhaps better phrasing. Most will be 0, but ET will
>> be set as it is a read-on
>>> On 10.06.15 at 16:53, wrote:
> El 10/06/15 a les 15.15, Jan Beulich ha escrit:
> On 10.06.15 at 14:34, wrote:
>> For my taste, it's getting too
>> close to something that could be a legitimate 32-bit kernel pointer
>> (agreed, all values could be valid pointers in 32-bit OSes, but with
>>
Sorry, forgot to reply to one of your chunks.
El 10/06/15 a les 15.15, Jan Beulich ha escrit:
>> * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits
>>are all undefined.
>
> I see that grub1 documentation says so, but I doubt this is realistic
> (even less so for cr4 bit
El 10/06/15 a les 15.18, Andrew Cooper ha escrit:
>> * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits
>>are all undefined.
>
> "unspecified" is perhaps better phrasing. Most will be 0, but ET will
> be set as it is a read-only bit in all processors Xen will function on
El 10/06/15 a les 15.15, Jan Beulich ha escrit:
On 10.06.15 at 14:34, wrote:
>> * XEN_ELFNOTE_PADDR_OFFSET: the offset of the ELF paddr field from the
>>actual required physical address.
>
> Why would that be needed? I.e. why would there ever be an offset?
For example a FreeBSD kernel
On 10/06/15 13:34, 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
>>> On 10.06.15 at 14:34, wrote:
> * XEN_ELFNOTE_PADDR_OFFSET: the offset of the ELF paddr field from the
>actual required physical address.
Why would that be needed? I.e. why would there ever be an offset?
> * XEN_ELFNOTE_PADDR_ENTRY: the 32bit entry point into the kernel.
> * XEN_ELFNOT
16 matches
Mail list logo
