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: Markus Armbruster
Subject: Re: [Qemu-devel] [PULL 15/54] build: convert pci.mak to Kconfig
Date: Thu, 14 Mar 2019 19:48:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

> On 14/03/19 14:03, David Abdurachmanov wrote:
>> Would it be enough to modify ./default-configs/riscv32-softmmu.mak by
>> adding:
>> 
>> CONFIG_PCIE_PORT=n
>
> The missing dependency is for any board that doesn't support MSI, not
> just RISC-V.
>
> Note that technically what we do with msi_nonbroken makes no sense from
> the PCI point of view.  An "MSI" is just a memory write so there is no
> such thing as a device that doesn't work because the board doesn't
> support MSI; it should be up to the OS not to configure MSI unless it
> knows the interrupt controller can be set up as a destination for MSIs.
>  The driver in the OS then can choose to use level-triggered interrupts
> (INTX) instead, or it can refuse to load.  At least, this is how QEMU
> *should* work.

Yes.

The problem is virtual interrupt controllers that claim to support MSI
when they don't.  The OS's probe returns "go ahead and use MSI", and the
system falls apart.

So we put in a lame work-around: if MSI is broken, mangle all PCI
devices to make them deny MSI capability.

The next problem is that we don't even know which of our interrupt
controllers have MSI working.  So we summarily declare them all broken,
then have the few we actually know declare themselves non-broken.

A bit of background in the thread around
Message-ID: <address@hidden>
https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg00983.html

> However, we started doing this msi_nonbroken thing, and therefore, since
> we can model it correctly with Kconfig and obtain the same results as
> pre-Kconfig, it's a better way to do it.

As long as the MSI mess exists, we deal with it as well as we can.



reply via email to

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