Re: [Xen-devel] [PATCH v5 00/16] x86: multiboot2 protocol support

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.08.16 at 16:15, <daniel.kiper@xxxxxxxxxx> wrote:
> On Mon, Aug 22, 2016 at 04:10:04AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43, <daniel.kiper@xxxxxxxxxx> wrote:
>> > The final goal is xen.efi binary file which could be loaded by EFI
>> > loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
>> > multiboot2 protocol. This way we will have:
>> >   - smaller Xen code base,
>> >   - one code base for xen.gz and xen.efi,
>> >   - one build method for xen.gz and xen.efi;
>> >     xen.efi will be extracted from xen(-syms)
>> >     file using objcopy or special custom tool,
>> >   - xen.efi build will not so strongly depend
>> >     on a given GCC and binutils version.
>>
>> Just in case you aren't aware: The partial revert done by
>> 0b8a172444 ("x86: partially revert use of 2M mappings for
>> hypervisor image") now puts us a step further away from that
>> goal, compared to when you had started your work.
> 
> I am not sure about that. Andrew patches changed xen.gz size significantly.
> My patches does not do that in significant way. They (precisely it) just
> move load address from 1 MiB to 2 MiB. So, I do not expect major issues
> here. However, anyway it should be tested (and it was tested, IIRC, by
> Konrad some time ago).

Looks like you didn't understand: This is not about image size. The
issue is that the EFI binary, other than xen.gz, now properly uses
RX, RO, and RW permissions (and large pages) for the individual
pieces of the image. Moving to a single binary would hence result
in a (slight) regression unless that gets taken care of beforehand.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel