Open Stack

W dniu 12.01.2018 o 16:54, Jeremy Stanley pisze:
> On 2018-01-12 16:06:03 +0100 (+0100), Marcin Juszkiewicz wrote:
>> Or someone will try to target q35/uefi emulation instead of i440fx 
>> one on x86 alone.
> 
> I'm curious why we'd need emulation there...

Developers around x86 virtualisation live in world where VM is like PC
from 90s (i440fx qemu model). You boot BIOS which reads bootloader from
1st sector of your storage, you have 32 PCI slots with hotplug etc. All
you need is VM + disk image with one partition using MBR partitioning.

If you want to have something which reminds Arm64 (but still is x86)
then you switch to Q35 qemu model and enable UEFI as bootloader. And all
your existing (and working with previous model) disk images with one
partition are useless. Your hotplug options are limited to amount of
pcie root ports defined in VM (usually 2-3). All your disk images need
to be converted to GPT partitioning, you need to have ESP (EFI System
Partition) partition with EFI bootloader stored there.

But (nearly) no one in x86 world goes for q35 model. Mostly because it
requires more work to be done and because users will ask why they can
not add 6th storage and 11th network card. And in arm64 world we do not
have such luck.

That's why I mentioned q35.

>> If I disable installing grub I can build useless one partition
>> disk image on arm64. Nothing will boot it.
> 
> See my other reply on this thread with a link to the bootloader 
> element. It seems like it's got support implemented for 
> multi-partition images needed by 64-bit PowerPC systems, so not 
> terribly dissimilar.

Firmware used by 64-bit Power system accepts MBR partitioned storage.

UEFI expects GPT and DIB is completely not prepared for it. I made
block-layout-arm64.yaml file and got it used just to see "sorry, mbr
expected" message. You have whole Python class to create MBR bit by bit
when few calls to 'sfdisk/gdisk' shell commands do the same.