All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>, Cornelia Huck <cohuck@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Collin Walling <walling@linux.ibm.com>,
	"open list\:RISC-V" <qemu-riscv@nongnu.org>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Sagar Karandikar <sagark@eecs.berkeley.edu>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Helge Deller <deller@gmx.de>, Palmer Dabbelt <palmer@sifive.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Aurelien Jarno <aurelien@aurel32.net>,
	"open list\:S390" <qemu-s390x@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-ppc <qemu-ppc@nongnu.org>,
	Richard Henderson <rth@twiddle.net>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-riscv] [Qemu-devel] [qemu-s390x] [RFC PATCH 1/3] hw/Kconfig: PCI bus implies PCI_DEVICES
Date: Mon, 15 Jul 2019 18:08:45 +0200	[thread overview]
Message-ID: <87a7dfth4i.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <6c39a198-e951-c0bd-1ddc-5d227afe72ff@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Mon, 15 Jul 2019 15:38:12 +0200")

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> 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é <philmd@redhat.com> wrote:
>>>
>>>> On 7/15/19 12:56 PM, Cornelia Huck wrote:
>>>>> On Mon, 15 Jul 2019 12:48:55 +0200
>>>>> Thomas Huth <thuth@redhat.com> wrote:
>>>>>   
>>>>>> On 15/07/2019 12.19, Peter Maydell wrote:  
>>>>>>> On Mon, 15 Jul 2019 at 11:15, Thomas Huth <thuth@redhat.com> 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é <philmd@redhat.com>
>>>>>>>>> ---    
>>>>>>>     
>>>>>>>>> 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?

What kinds of PCI devices are we trying to name?

Is it INTx vs. MSI vs. MSI-X?

Is it Conventional PCI vs. PCI Express?


WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Collin Walling <walling@linux.ibm.com>,
	Sagar Karandikar <sagark@eecs.berkeley.edu>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	Gerd Hoffmann <kraxel@redhat.com>, Helge Deller <deller@gmx.de>,
	Richard Henderson <rth@twiddle.net>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	Thomas Huth <thuth@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"open list:S390" <qemu-s390x@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	Cornelia Huck <cohuck@redhat.com>, qemu-ppc <qemu-ppc@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-arm] [Qemu-devel] [qemu-s390x] [RFC PATCH 1/3] hw/Kconfig: PCI bus implies PCI_DEVICES
Date: Mon, 15 Jul 2019 18:08:45 +0200	[thread overview]
Message-ID: <87a7dfth4i.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <6c39a198-e951-c0bd-1ddc-5d227afe72ff@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Mon, 15 Jul 2019 15:38:12 +0200")

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> 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é <philmd@redhat.com> wrote:
>>>
>>>> On 7/15/19 12:56 PM, Cornelia Huck wrote:
>>>>> On Mon, 15 Jul 2019 12:48:55 +0200
>>>>> Thomas Huth <thuth@redhat.com> wrote:
>>>>>   
>>>>>> On 15/07/2019 12.19, Peter Maydell wrote:  
>>>>>>> On Mon, 15 Jul 2019 at 11:15, Thomas Huth <thuth@redhat.com> 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é <philmd@redhat.com>
>>>>>>>>> ---    
>>>>>>>     
>>>>>>>>> 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?

What kinds of PCI devices are we trying to name?

Is it INTx vs. MSI vs. MSI-X?

Is it Conventional PCI vs. PCI Express?

WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Collin Walling <walling@linux.ibm.com>,
	Sagar Karandikar <sagark@eecs.berkeley.edu>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	Gerd Hoffmann <kraxel@redhat.com>, Helge Deller <deller@gmx.de>,
	Richard Henderson <rth@twiddle.net>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	Thomas Huth <thuth@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"open list:S390" <qemu-s390x@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	Cornelia Huck <cohuck@redhat.com>, qemu-ppc <qemu-ppc@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [qemu-s390x] [RFC PATCH 1/3] hw/Kconfig: PCI bus implies PCI_DEVICES
Date: Mon, 15 Jul 2019 18:08:45 +0200	[thread overview]
Message-ID: <87a7dfth4i.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <6c39a198-e951-c0bd-1ddc-5d227afe72ff@redhat.com> ("Philippe Mathieu-Daudé"'s message of "Mon, 15 Jul 2019 15:38:12 +0200")

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> 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é <philmd@redhat.com> wrote:
>>>
>>>> On 7/15/19 12:56 PM, Cornelia Huck wrote:
>>>>> On Mon, 15 Jul 2019 12:48:55 +0200
>>>>> Thomas Huth <thuth@redhat.com> wrote:
>>>>>   
>>>>>> On 15/07/2019 12.19, Peter Maydell wrote:  
>>>>>>> On Mon, 15 Jul 2019 at 11:15, Thomas Huth <thuth@redhat.com> 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é <philmd@redhat.com>
>>>>>>>>> ---    
>>>>>>>     
>>>>>>>>> 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?

What kinds of PCI devices are we trying to name?

Is it INTx vs. MSI vs. MSI-X?

Is it Conventional PCI vs. PCI Express?


  parent reply	other threads:[~2019-07-15 16:09 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-15  9:55 [Qemu-riscv] [PATCH 0/3] hw/Kconfig: PCI & USB fixes Philippe Mathieu-Daudé
2019-07-15  9:55 ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-07-15  9:55 ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-07-15  9:55 ` [Qemu-riscv] [RFC PATCH 1/3] hw/Kconfig: PCI bus implies PCI_DEVICES Philippe Mathieu-Daudé
2019-07-15  9:55   ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-07-15  9:55   ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-07-15 10:15   ` [Qemu-riscv] " Thomas Huth
2019-07-15 10:15     ` [Qemu-devel] " Thomas Huth
2019-07-15 10:15     ` [Qemu-arm] " Thomas Huth
2019-07-15 10:19     ` [Qemu-riscv] " Peter Maydell
2019-07-15 10:19       ` [Qemu-devel] " Peter Maydell
2019-07-15 10:19       ` [Qemu-arm] " Peter Maydell
2019-07-15 10:48       ` [Qemu-riscv] " Thomas Huth
2019-07-15 10:48         ` [Qemu-devel] " Thomas Huth
2019-07-15 10:48         ` [Qemu-arm] " Thomas Huth
2019-07-15 10:56         ` [Qemu-riscv] [qemu-s390x] " Cornelia Huck
2019-07-15 10:56           ` [Qemu-devel] " Cornelia Huck
2019-07-15 10:56           ` [Qemu-arm] " Cornelia Huck
2019-07-15 11:04           ` [Qemu-riscv] " Philippe Mathieu-Daudé
2019-07-15 11:04             ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-07-15 11:04             ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-07-15 11:09             ` [Qemu-riscv] " Cornelia Huck
2019-07-15 11:09               ` [Qemu-devel] " Cornelia Huck
2019-07-15 11:09               ` [Qemu-arm] " Cornelia Huck
2019-07-15 13:19               ` [Qemu-riscv] " Thomas Huth
2019-07-15 13:19                 ` [Qemu-devel] " Thomas Huth
2019-07-15 13:19                 ` [Qemu-arm] " Thomas Huth
2019-07-15 13:38                 ` [Qemu-riscv] " Philippe Mathieu-Daudé
2019-07-15 13:38                   ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-07-15 13:38                   ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-07-15 13:49                   ` [Qemu-riscv] " Thomas Huth
2019-07-15 13:49                     ` [Qemu-devel] " Thomas Huth
2019-07-15 13:49                     ` [Qemu-arm] " Thomas Huth
2019-07-15 16:08                   ` Markus Armbruster [this message]
2019-07-15 16:08                     ` [Qemu-devel] " Markus Armbruster
2019-07-15 16:08                     ` [Qemu-arm] " Markus Armbruster
2019-07-15 16:12                     ` [Qemu-riscv] " Cornelia Huck
2019-07-15 16:12                       ` Cornelia Huck
2019-07-15 16:12                       ` [Qemu-arm] " Cornelia Huck
2019-07-15 18:22                       ` [Qemu-riscv] " Paolo Bonzini
2019-07-15 18:22                         ` Paolo Bonzini
2019-07-15 18:22                         ` [Qemu-arm] " Paolo Bonzini
2019-07-16 13:06                         ` [Qemu-riscv] " Markus Armbruster
2019-07-16 13:06                           ` Markus Armbruster
2019-07-16 13:06                           ` [Qemu-arm] " Markus Armbruster
2019-07-16 15:04                           ` [Qemu-riscv] " Thomas Huth
2019-07-16 15:04                             ` Thomas Huth
2019-07-16 15:04                             ` [Qemu-arm] " Thomas Huth
2019-07-17 12:59                             ` [Qemu-riscv] " Collin Walling
2019-07-17 12:59                               ` Collin Walling
2019-07-17 13:52                               ` [Qemu-riscv] " Paolo Bonzini
2019-07-17 13:52                                 ` Paolo Bonzini
2019-07-17 13:52                                 ` [Qemu-arm] " Paolo Bonzini
2019-07-17 14:54                                 ` [Qemu-riscv] " Collin Walling
2019-07-17 14:54                                   ` Collin Walling
2019-07-17 14:54                                   ` [Qemu-arm] " Collin Walling
2019-07-17 15:04                                   ` [Qemu-riscv] " Paolo Bonzini
2019-07-17 15:04                                     ` Paolo Bonzini
2019-07-17 15:04                                     ` [Qemu-arm] " Paolo Bonzini
2019-07-18 15:33                                     ` [Qemu-riscv] " Cornelia Huck
2019-07-18 15:33                                       ` Cornelia Huck
2019-07-18 15:33                                       ` [Qemu-arm] " Cornelia Huck
2019-07-22 13:40                             ` [Qemu-riscv] " Markus Armbruster
2019-07-22 13:40                               ` Markus Armbruster
2019-07-22 13:40                               ` [Qemu-arm] " Markus Armbruster
2019-07-15  9:55 ` [Qemu-riscv] [PATCH-for-4.2 2/3] hw/usb/Kconfig: Add CONFIG_USB_EHCI_PCI Philippe Mathieu-Daudé
2019-07-15  9:55   ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-07-15  9:55   ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-07-15 10:54   ` [Qemu-riscv] [Qemu-ppc] " BALATON Zoltan
2019-07-15 10:54     ` [Qemu-devel] " BALATON Zoltan
2019-07-15 10:54     ` [Qemu-arm] " BALATON Zoltan
2019-07-15 11:03     ` [Qemu-riscv] " Thomas Huth
2019-07-15 11:03       ` [Qemu-devel] " Thomas Huth
2019-07-15 11:03       ` [Qemu-arm] " Thomas Huth
2019-07-15 11:10       ` [Qemu-riscv] " BALATON Zoltan
2019-07-15 11:10         ` [Qemu-devel] " BALATON Zoltan
2019-07-15 11:19         ` [Qemu-riscv] " Thomas Huth
2019-07-15 11:19           ` [Qemu-devel] " Thomas Huth
2019-07-15 11:19           ` [Qemu-arm] " Thomas Huth
2019-07-15 11:20         ` [Qemu-riscv] " Paolo Bonzini
2019-07-15 11:20           ` [Qemu-devel] " Paolo Bonzini
2019-07-15 11:20           ` [Qemu-arm] " Paolo Bonzini
2019-07-15 11:01   ` [Qemu-riscv] " Thomas Huth
2019-07-15 11:01     ` [Qemu-devel] " Thomas Huth
2019-07-15 11:01     ` [Qemu-arm] " Thomas Huth
2019-07-15  9:55 ` [Qemu-riscv] [PATCH-for-4.1? 3/3] hw/usb/Kconfig: USB_XHCI_NEC requires USB_XHCI Philippe Mathieu-Daudé
2019-07-15  9:55   ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-07-15  9:55   ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-07-15 10:50   ` [Qemu-trivial] " Thomas Huth
2019-07-15 10:50     ` [Qemu-devel] " Thomas Huth
2019-07-15 10:50     ` [Qemu-arm] " Thomas Huth
2019-07-15 10:50     ` [Qemu-riscv] " Thomas Huth
2019-07-15 11:21 ` [Qemu-riscv] [PATCH 0/3] hw/Kconfig: PCI & USB fixes Paolo Bonzini
2019-07-15 11:21   ` [Qemu-devel] " Paolo Bonzini
2019-07-15 11:21   ` [Qemu-arm] " Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7dfth4i.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=atar4qemu@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=deller@gmx.de \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mst@redhat.com \
    --cc=palmer@sifive.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sagark@eecs.berkeley.edu \
    --cc=thuth@redhat.com \
    --cc=walling@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.