>>> On 31.08.15 at 21:49, wrote:
> On Fri, Aug 28, 2015 at 08:16:05AM -0600, Jan Beulich wrote:
>> >>> On 28.08.15 at 15:42, wrote:
>> > Now that said - do you have suggestions on how to make this work
>> > with GRUB in the picture?
>>
>> ... I don't think I'm the one to make suggestions on how t
On Fri, Aug 28, 2015 at 08:16:05AM -0600, Jan Beulich wrote:
> >>> On 28.08.15 at 15:42, wrote:
> > And I am not comfortable to say 'GRUB2+Xen cannot run on this hardware
> > because your firmware vendor is not following the EFI spec in spirit.'
>
> Well, not the least since I don't really agree w
>>> On 27.08.15 at 17:29, wrote:
> You're right, there's no such requirement on memory use in the spec.
> But you're missing the point. Supporting grub2 on UEFI is already a
> hack (ignoring all intentions EFI had from its first days). And now
> you've found an environment where that hack needs an
>>> On 28.08.15 at 15:42, wrote:
> And I am not comfortable to say 'GRUB2+Xen cannot run on this hardware
> because your firmware vendor is not following the EFI spec in spirit.'
Well, not the least since I don't really agree with this (albeit I can
see where you're coming from) ...
> Now that s
On Fri, Aug 28, 2015 at 02:22:46AM -0600, Jan Beulich wrote:
> >>> On 27.08.15 at 19:56, <426...@gmail.com> wrote:
> >> If you advocate direct booting ( no boot loader) on production machines I
> > wont argue much, as long as there is good recovery tools to deal with
> > failed boots (grub does th
On 28/08/15 07:54, Jan Beulich wrote:
>
>> Therefore I am very much +1 get grub working.
> Then you kind of misunderstood: I'm not against getting grub2
> working (i.e. patches prior to this one are fine in principle). What
> I'm against is hacking around firmware+grub2 combinations not
> suitable
>>> On 27.08.15 at 19:56, <426...@gmail.com> wrote:
>> If you advocate direct booting ( no boot loader) on production machines I
> wont argue much, as long as there is good recovery tools to deal with
> failed boots (grub does this very well, I am not aware of anything
> comparable that is pure ef
>>> On 27.08.15 at 20:04, wrote:
> On 27/08/15 16:29, Jan Beulich wrote:
> On 27.08.15 at 17:10, wrote:
>>> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
>>> On 20.07.15 at 16:29, wrote:
> /* Copy bootstrap trampoline to low memory, below 1MB. */
> -
On 27/08/15 16:29, Jan Beulich wrote:
On 27.08.15 at 17:10, wrote:
>> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
>> On 20.07.15 at 16:29, wrote:
/* Copy bootstrap trampoline to low memory, below 1MB. */
-mov $sym_phys(trampoline_start),%es
On Thu, Aug 27, 2015 at 9:29 AM, Jan Beulich wrote:
> >>> On 27.08.15 at 17:10, wrote:
> > On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
> >> >>> On 20.07.15 at 16:29, wrote:
> >> > /* Copy bootstrap trampoline to low memory, below 1MB. */
> >> > -mov $sym_ph
>>> On 27.08.15 at 17:10, wrote:
> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29, wrote:
>> > /* Copy bootstrap trampoline to low memory, below 1MB. */
>> > -mov $sym_phys(trampoline_start),%esi
>> > +lea sym_offset(tramp
On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
> >>> On 20.07.15 at 16:29, wrote:
[...]
> > /* Copy bootstrap trampoline to low memory, below 1MB. */
> > -mov $sym_phys(trampoline_start),%esi
> > +lea sym_offset(trampoline_start)(%ebp),%esi
> >
>>> On 20.07.15 at 16:29, wrote:
> - %fs register is filled with segment descriptor which describes memory
> region
> with Xen image (it could be relocated or not);
This is too fuzzy. Please be very precise which region it is that %fs
is supposed to point to (so that reviewers have a chanc
> > > trampoline_bios_setup:
> > > +mov %ebp,%esi
> > > +
> > > +/* Initialise GDT and basic data segments. */
> > > +add %ebp,sym_offset(gdt_boot_descr_addr)(%esi)
> > > +lgdtsym_offset(gdt_boot_descr)(%esi)
> > > +
> > > +mov $BOOT_DS,%ecx
>>> On 14.08.15 at 16:37, wrote:
> On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote:
>> >>> On 14.08.15 at 15:59, wrote:
>> > On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
>> >> >>> On 14.08.15 at 13:52, wrote:
>> >> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rz
On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote:
> >>> On 14.08.15 at 15:59, wrote:
> > On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
> >> >>> On 14.08.15 at 13:52, wrote:
> >> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
> >> >> On Mon, Jul
>>> On 14.08.15 at 15:59, wrote:
> On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
>> >>> On 14.08.15 at 13:52, wrote:
>> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
>> >> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
>> >> > diff --git a/
On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
> >>> On 14.08.15 at 13:52, wrote:
> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
> >> > diff --git a/xen/include/asm-x86/page.h b/xen/include
>>> On 14.08.15 at 13:52, wrote:
> On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
>> > diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
>> > index 87b3341..27481ac 100644
>> > --- a/xen/inc
On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
> > Every multiboot protocol (regardless of version) compatible image must
> > specify its load address (in ELF or multiboot header). Multiboot protocol
> > compati
On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
> Every multiboot protocol (regardless of version) compatible image must
> specify its load address (in ELF or multiboot header). Multiboot protocol
> compatible loader have to load image at specified address. However, there
> is no guar
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 1
22 matches
Mail list logo
