[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-riscv] [Qemu-devel] [PULL 15/54] build: convert pci.mak to Kco
From: |
Andrea Bolognani |
Subject: |
Re: [Qemu-riscv] [Qemu-devel] [PULL 15/54] build: convert pci.mak to Kconfig |
Date: |
Thu, 14 Mar 2019 13:53:48 +0100 |
User-agent: |
Evolution 3.30.5 (3.30.5-1.fc29) |
On Mon, 2019-03-04 at 19:19 +0100, Paolo Bonzini wrote:
> Instead of including the same list of devices for each target,
> set CONFIG_PCI to true, and make the devices default to present
> whenever PCI is available. However, s390x does not want all the
> PCI devices, so there is a separate symbol to enable them.
[...]
> +++ b/default-configs/riscv32-softmmu.mak
> @@ -1,8 +1,8 @@
> # Default configuration for riscv-softmmu
>
> -include pci.mak
> include usb.mak
> -
> +CONFIG_PCI=y
> +CONFIG_PCI_DEVICES=y
> CONFIG_SERIAL=y
> CONFIG_VIRTIO_MMIO=y
I *think* this might have caused some unwanted changes for RISC-V.
pcie-root-port is built into qemu-system-riscv64 by default as of
dbbc277510aa (along with ioh3420!), but if you actually try to use it
you'll get:
$ ./riscv64-softmmu/qemu-system-riscv64 \
-M virt \
-device pcie-root-port
qemu-system-riscv64: -device pcie-root-port: MSI-X is not
supported by interrupt controller
This is a limitation we have been aware of, and the plan was to
enable the device in QEMU once it had been addressed: from the
libvirt side, the availability of the device would have meant that it
was safe to use it, but if the device is enabled in QEMU before it
can actually be used, then that makes detection on the libvirt side
problematic.
I haven't spent time digging further - and I'm not familiar enough
with the QEMU build system anyway O:-) - but I wouldn't be surprised
if the same happened for other architectures, too.
--
Andrea Bolognani / Red Hat / Virtualization
- Re: [Qemu-riscv] [Qemu-devel] [PULL 15/54] build: convert pci.mak to Kconfig,
Andrea Bolognani <=