qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 15/54] build: convert pci.mak to Kconfig


From: Andrea Bolognani
Subject: Re: [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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]