On 14.06.2014 01:10, Peter Crosthwaite wrote: > On Thu, Jun 12, 2014 at 2:01 AM, Claudio Fontana > <claudio.font...@huawei.com> 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 <peter.mayd...@linaro.org> >>> --- >>> 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("/pl031@%" 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