qemu-riscv
[Top][All Lists]
Advanced

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

Re: [Qemu-riscv] [qemu-s390x] [RFC PATCH 1/3] hw/Kconfig: PCI bus implie


From: Thomas Huth
Subject: Re: [Qemu-riscv] [qemu-s390x] [RFC PATCH 1/3] hw/Kconfig: PCI bus implies PCI_DEVICES
Date: Mon, 15 Jul 2019 15:49:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

On 15/07/2019 15.38, Philippe Mathieu-Daudé wrote:
> On 7/15/19 3:19 PM, Thomas Huth wrote:
>> On 15/07/2019 13.09, Cornelia Huck wrote:
>>> On Mon, 15 Jul 2019 13:04:28 +0200
>>> Philippe Mathieu-Daudé <address@hidden> wrote:
>>>
>>>> On 7/15/19 12:56 PM, Cornelia Huck wrote:
>>>>> On Mon, 15 Jul 2019 12:48:55 +0200
>>>>> Thomas Huth <address@hidden> wrote:
>>>>>   
>>>>>> On 15/07/2019 12.19, Peter Maydell wrote:  
>>>>>>> On Mon, 15 Jul 2019 at 11:15, Thomas Huth <address@hidden> wrote:    
>>>>>>>>
>>>>>>>> On 15/07/2019 11.55, Philippe Mathieu-Daudé wrote:    
>>>>>>>>> If a controller device provides a PCI bus, we can plug any PCI
>>>>>>>>> daughter card on it.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
>>>>>>>>> ---    
>>>>>>>     
>>>>>>>>> diff --git a/hw/pci/Kconfig b/hw/pci/Kconfig
>>>>>>>>> index 77f8b005ff..0f7267db35 100644
>>>>>>>>> --- a/hw/pci/Kconfig
>>>>>>>>> +++ b/hw/pci/Kconfig
>>>>>>>>> @@ -1,5 +1,6 @@
>>>>>>>>>  config PCI
>>>>>>>>>      bool
>>>>>>>>> +    imply PCI_DEVICES    
>>>>>>>>
>>>>>>>> No, please don't change this. This was done on purpose, since almost 
>>>>>>>> all
>>>>>>>> PCI_DEVICES do not work on s390x (so s390x does *not* imply 
>>>>>>>> PCI_DEVICES).    
>>>>>>>
>>>>>>> But that means that every board that provides PCI has to have an
>>>>>>> "imply PCI_DEVICES" line, which is pretty clunky just to work
>>>>>>> around an s390x limitation.
>>>>>>>
>>>>>>> Is there some way in the Kconfig syntax for s390x to say
>>>>>>> "no PCI_DEVICES" so we can have the corner-case be handled
>>>>>>> by the s390x Kconfig in one place rather than in 20 places
>>>>>>> affecting everywhere except s390x?    
>>>>>>
>>>>>> IIRC the problem on s390x are the legacy IRQs. s390x has only MSIs. So I
>>>>>> guess the correct way to fix this would be to introduce some
>>>>>> PCI_LEGACY_IRQ switch and let all old devices that do not work with MSI
>>>>>> depend on it.  
>>>>>
>>>>> s/MSI/MSI-X/, IIRC. Not sure how far 'legacy' would stretch.  
>>>>
>>>> Maybe we can have something like PCI_LEGACY_DEVICES and PCI_MSI_DEVICES?
>>>>
>>>> So if s390x only selects PCI_LEGACY (not PCI_MSI) bus, then it only get
>>>> legacy devices?
>>>
>>> Wrong way around? We need MSI-X for s390x, not plain MSI or
>>> 'legacy' (whatever that is).
>>
>> With "legacy" I meant the old level-triggered interrupts from the early
>> PCI (non-express) days. Sorry for being imprecise here.
>>
>> So maybe we need two new switches, PCI_CLASSIC (or so) and PCI_MSIX, and
>> then the PCI devices should be marked with "default y if PCI_CLASSIC" if
>> they do not have MSIX support, and with "default y if PCI_MSIX" if they
>> have MSI-X support?
> 
> Something like that :)
> 
> Per Wikipedia:
> 
>   Conventional PCI and PCI-X are sometimes called Parallel PCI
>   in order to distinguish them technologically from their more
>   recent successor PCI Express, which adopted a serial,
>   lane-based architecture.
> 
>   The PCI-SIG introduced the serial PCI Express in c. 2004. At
>   the same time, they renamed PCI as Conventional PCI.
> 
>   PCI Express does not have physical interrupt lines at all.
>   It uses message-signaled interrupts exclusively.
> 
> What about PCI_CONVENTIONAL then?

Sounds good to me.

 Thomas



reply via email to

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