[Qemu-devel] hw/arm/virt: Provide PCI?

[Claudio Fontana]

On 14.06.2014 01:10, Peter Crosthwaite wrote:
> On Thu, Jun 12, 2014 at 2:01 AM, Claudio Fontana
> <address@hidden> wrote:
>> On 10.06.2014 19:06, Peter Maydell wrote:
>>> UEFI mandates that the platform must include an RTC, so provide
>>> one in 'virt', using the PL031.
>>>
>>> Signed-off-by: Peter Maydell <address@hidden>
>>> ---
>>>  hw/arm/virt.c | 30 ++++++++++++++++++++++++++++++
>>>  1 file changed, 30 insertions(+)
>>>
>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>>> index e658eb0..b60928e 100644
>>> --- a/hw/arm/virt.c
>>> +++ b/hw/arm/virt.c
>>> @@ -66,6 +66,7 @@ enum {
>>>      VIRT_GIC_CPU,
>>>      VIRT_UART,
>>>      VIRT_MMIO,
>>> +    VIRT_RTC,
>>>  };
>>>
>>>  typedef struct MemMapEntry {
>>> @@ -93,6 +94,8 @@ typedef struct VirtBoardInfo {
>>>   * high memory region beyond 4GB).
>>>   * This represents a compromise between how much RAM can be given to
>>>   * a 32 bit VM and leaving space for expansion and in particular for PCI.
>>> + * Note that devices should generally be placed at multiples of 0x10000,
>>> + * to accommodate guests using 64K pages.
>>>   */
>>>  static const MemMapEntry a15memmap[] = {
>>>      [VIRT_FLASH] = { 0, 0x8000000 },
>>> @@ -101,6 +104,7 @@ static const MemMapEntry a15memmap[] = {
>>>      [VIRT_GIC_DIST] = { 0x8000000, 0x10000 },
>>>      [VIRT_GIC_CPU] = { 0x8010000, 0x10000 },
>>>      [VIRT_UART] = { 0x9000000, 0x1000 },
>>> +    [VIRT_RTC] = { 0x90010000, 0x1000 },
>>>      [VIRT_MMIO] = { 0xa000000, 0x200 },
>>>      /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that 
>>> size */
>>>      /* 0x10000000 .. 0x40000000 reserved for PCI */
>>> @@ -109,6 +113,7 @@ static const MemMapEntry a15memmap[] = {
>>>
>>>  static const int a15irqmap[] = {
>>>      [VIRT_UART] = 1,
>>> +    [VIRT_RTC] = 2,
>>>      [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */
>>>  };
>>>
>>> @@ -340,6 +345,29 @@ static void create_uart(const VirtBoardInfo *vbi, 
>>> qemu_irq *pic)
>>>      g_free(nodename);
>>>  }
>>>
>>> +static void create_rtc(const VirtBoardInfo *vbi, qemu_irq *pic)
>>> +{
>>> +    char *nodename;
>>> +    hwaddr base = vbi->memmap[VIRT_RTC].base;
>>> +    hwaddr size = vbi->memmap[VIRT_RTC].size;
>>> +    int irq = vbi->irqmap[VIRT_RTC];
>>> +    const char compat[] = "arm,pl031\0arm,primecell";
>>> +
>>> +    sysbus_create_simple("pl031", base, pic[irq]);
>>> +
>>> +    nodename = g_strdup_printf("/address@hidden" PRIx64, base);
>>> +    qemu_fdt_add_subnode(vbi->fdt, nodename);
>>> +    qemu_fdt_setprop(vbi->fdt, nodename, "compatible", compat, 
>>> sizeof(compat));
>>> +    qemu_fdt_setprop_sized_cells(vbi->fdt, nodename, "reg",
>>> +                                 2, base, 2, size);
>>> +    qemu_fdt_setprop_cells(vbi->fdt, nodename, "interrupts",
>>> +                           GIC_FDT_IRQ_TYPE_SPI, irq,
>>> +                           GIC_FDT_IRQ_FLAGS_EDGE_LO_HI);
>>> +    qemu_fdt_setprop_cell(vbi->fdt, nodename, "clocks", 
>>> vbi->clock_phandle);
>>> +    qemu_fdt_setprop_string(vbi->fdt, nodename, "clock-names", "apb_pclk");
>>> +    g_free(nodename);
>>> +}
>>> +
>>>  static void create_virtio_devices(const VirtBoardInfo *vbi, qemu_irq *pic)
>>>  {
>>>      int i;
>>> @@ -524,6 +552,8 @@ static void machvirt_init(MachineState *machine)
>>>
>>>      create_uart(vbi, pic);
>>>
>>> +    create_rtc(vbi, pic);
>>> +
>>>      /* Create mmio transports, so the user can create virtio backends
>>>       * (which will be automatically plugged in to the transports). If
>>>       * no backend is created the transport will just sit harmlessly idle.
>>>
>>
>> I am quite happy with the RTC device being added to the virt platform, as 
>> this will move me from 1970 in the guest, where I am at the moment. :)
>>
>> One question I would have is, what would be the best/recommended way as a 
>> user of the virt platform
>> to add buses and devices to the platform? Is using virt as the base 
>> platform, and extending it with additional buses and devices a sensible 
>> thing to do?
>>
> 
> Yes.
> 
>> In my case I am particularly interested in the possibility to add a PCI-E 
>> bus to the platform in some (any) way, so that QEMU provides support for 
>> that, one that does not mean maintaining a separate patchset. Is extending 
>> via --device a viable option?
>> New machine model?
> 
> For PCI support it should just be a case of adding a PCI controller to
> the virt board, then -device should just work for pci devs.

Thanks for your answer; that seems straightforward enough, so would a patch to 
add pci to the virt board be acceptable?

virt.c shows that there is already a reserved space in the mem map for that.

Thank you,

Claudio