Re: [Qemu-arm] [Qemu-devel] [PATCH] hw/arm: Add SBSA machine type

[Hongbo Zhang]

On 27 June 2018 at 22:56, Igor Mammedov <address@hidden> wrote:
> On Wed, 27 Jun 2018 18:13:08 +0800
> Hongbo Zhang <address@hidden> wrote:
>
>> This patch introduces a new Arm machine type 'SBSA' with features:
>>  - Based on legacy 'virt' machine type.
>>  - Newly designed memory map.
>>  - EL2 and EL3 are enabled by default.
>>  - AHCI controller attached to system bus, and then CDROM and hard disc
>>    can be added to it.
>>  - EHCI controller attached to system bus, with USB mouse and key board
>>    installed by default.
>>  - E1000 ethernet card on PCIE bus.
>>  - VGA display adaptor on PCIE bus.
>>  - Default CPU type cortex-a57, 4 cores, and 1G bytes memory.
>>  - No virtio functions enabled, since this is to emulate real hardware.
> I'd drop all default (convenience) devices unless they are specified in SBSA,
> and make management explicitly provide needed devices on CLI.
>
Thanks for review.

I mentioned these default values because they are different from the
'virt' machine from which this sbsa machine derives. (sbsa has uart
too, it is same with 'virt' PL011).
Qemu implementation should has such default values, if the sbsa
machine does not offer them, they fallback to the parent machine's.
The parent 'virt' machine's default cpu type is cortext-a15, that is
not proper for a armv8 server, and its default memory is 128M, that is
not enough to load uefi, even 512M cannot either, so I set the sbsa
defualt minimal memory to 1G.

The core numbers, is a new default. Server is smp in common sense,
single core isn't like a server, so some even want to set to max
capability as default, but this isn't good either I think, because
gicv3 memory space in Qemu can even support more than 200 cores, that
is too much.
(gicv2 currently support 8 cores, but there are issues to boot smp for
both gicv2 and gicv3 now, it should be another thread)

>>
>> This is the prototype, more features can be added in futrue.
>>
>> Purpose of this is to have a standard QEMU platform for Arm firmware
>> developement etc. where the legacy machines cannot meets requirements.
>>
>> Arm Trusted Firmware and UEFI porting to this are done seperately.
>>
>> Signed-off-by: Hongbo Zhang <address@hidden>
>> ---
> [...]
>
>> @@ -94,6 +98,8 @@
>>
>>  #define PLATFORM_BUS_NUM_IRQS 64
>>
>> +#define SATA_NUM_PORTS 6
>> +
>>  /* RAM limit in GB. Since VIRT_MEM starts at the 1GB mark, this means
>>   * RAM can go up to the 256GB mark, leaving 256GB of the physical
>>   * address space unallocated and free for future use between 256G and 512G.
>> @@ -168,6 +174,47 @@ static const int a15irqmap[] = {
>>      [VIRT_PLATFORM_BUS] = 112, /* ...to 112 + PLATFORM_BUS_NUM_IRQS -1 */
>>  };
>>
>> +static const MemMapEntry sbsa_memmap[] = {
>> +    /* Space up to 0x8000000 is reserved for a boot ROM */
>> +    [VIRT_FLASH] =              {          0, 0x08000000 },
>> +    [VIRT_CPUPERIPHS] =         { 0x08000000, 0x00020000 },
>> +    /* GIC distributor and CPU interfaces sit inside the CPU peripheral 
>> space */
>> +    [VIRT_GIC_DIST] =           { 0x08000000, 0x00010000 },
>> +    [VIRT_GIC_CPU] =            { 0x08010000, 0x00010000 },
>> +    [VIRT_GIC_V2M] =            { 0x08020000, 0x00001000 },
>> +    /* The space in between here is reserved for GICv3 CPU/vCPU/HYP */
>> +    [VIRT_GIC_ITS] =            { 0x08080000, 0x00020000 },
>> +    /* This redistributor space allows up to 2*64kB*123 CPUs */
>> +    [VIRT_GIC_REDIST] =         { 0x080A0000, 0x00F60000 },
>> +    [VIRT_UART] =               { 0x09000000, 0x00001000 },
>> +    [VIRT_RTC] =                { 0x09010000, 0x00001000 },
>> +    [VIRT_FW_CFG] =             { 0x09020000, 0x00000018 },
>> +    [VIRT_GPIO] =               { 0x09030000, 0x00001000 },
>> +    [VIRT_SECURE_UART] =        { 0x09040000, 0x00001000 },
>> +    [VIRT_AHCI] =               { 0x09050000, 0x00010000 },
>> +    [VIRT_EHCI] =               { 0x09060000, 0x00010000 },
>> +    [VIRT_PLATFORM_BUS] =       { 0x0c000000, 0x02000000 },
>> +    [VIRT_SECURE_MEM] =         { 0x0e000000, 0x01000000 },
>> +    [VIRT_PCIE_MMIO] =          { 0x10000000, 0x7fff0000 },
>> +    [VIRT_PCIE_PIO] =           { 0x8fff0000, 0x00010000 },
>> +    [VIRT_PCIE_ECAM] =          { 0x90000000, 0x10000000 },
>> +    /* Second PCIe window, 508GB wide at the 4GB boundary */
>> +    [VIRT_PCIE_MMIO_HIGH] =     { 0x100000000ULL, 0x7F00000000ULL },
>> +    [VIRT_MEM] =                { 0x8000000000ULL, RAMLIMIT_BYTES },
> does spec require support for 32-bit guest or is it only 64bit,
> if the later I'd put it somewhere high where we can increase region
> to terrabytes.
>
Spec only requires it to be compliant with armv8.
Designed purpose of this is to run 64bit guests, because in practice
an arm server is usually 64bit.

> another idea that was floating around (considering we don't care about legacy)
> is to use flexible base address and tell firmware[*] via register where it's.
> Then it would be able to support 32 guest with small amount of RAM
> and 64 bit guests with huge amount of RAM using a single memory range.
> (to keep memory management simple). It's also future friendly, as in case
> if we need to move it we could do easily by changing base address for new 
> machine
> type only and firmware would automatically pick it up from register
> (without all compat nightmare we have with 2 regions in pc/q35 machines).
>
> [*] When I've talked with Laszlo about it he said it was not easy to do in 
> uefi
> but still possible.
Sounds not easy.
I think the first step is to get this merged, and then we can add more
features if necessary.
I've already seen some points in trusted firmware and uefi need to be fixed.

>
> same applies to GIG regions/mmio/ecam where we are twisting our hands when 
> trying to
> increase number of things.
>
> [...]
>