On Fri, 22 Mar 2024 at 14:08, Cédric Le Goater wrote:
>
> On 3/20/24 16:00, Peter Maydell wrote:
> > On Wed, 20 Mar 2024 at 14:10, Mark Burton wrote:
> >> I’d broaden this to all ’signals’ (IRQ, Reset etc) - and I guess
> >> similar statements apply, with the “bridge” between the function
> >>
On 3/20/24 16:00, Peter Maydell wrote:
On Wed, 20 Mar 2024 at 14:10, Mark Burton wrote:
I’d broaden this to all ’signals’ (IRQ, Reset etc) - and I guess
similar statements apply, with the “bridge” between the function
and the GPIO mechanism moved closer or further from the originator(s)
of the
> On 20 Mar 2024, at 16:00, Peter Maydell wrote:
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> On Wed, 20 Mar 2024 at 14:10, Mark Burton wrote:
>> I’d broaden this to all ’signals’ (IRQ, Reset etc) -
On Wed, 20 Mar 2024 at 14:10, Mark Burton wrote:
> I’d broaden this to all ’signals’ (IRQ, Reset etc) - and I guess
> similar statements apply, with the “bridge” between the function
> and the GPIO mechanism moved closer or further from the originator(s)
> of the activity.
>
> The issue isn’t my
> On 20 Mar 2024, at 14:55, Peter Maydell wrote:
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> On Wed, 20 Mar 2024 at 12:31, Mark Burton wrote:
>>> On 20 Mar 2024, at 13:00, Peter Maydell wrote:
>>>
On Wed, 20 Mar 2024 at 12:31, Mark Burton wrote:
> > On 20 Mar 2024, at 13:00, Peter Maydell wrote:
> > What NMI probably ought to be is board-specific: so it's like
> > having some notional front panel switch labeled "NMI", and the
>
> Do the youngsters of today know what one of those is ?
>
> On 20 Mar 2024, at 13:00, Peter Maydell wrote:
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> On Wed, 20 Mar 2024 at 11:20, Philippe Mathieu-Daudé
> wrote:
>>
>> On 20/2/24 16:19, Thomas Huth
On Wed, 20 Mar 2024 at 11:20, Philippe Mathieu-Daudé wrote:
>
> On 20/2/24 16:19, Thomas Huth wrote:
> > On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
> >> Have s390x always deliver NMI to the first CPU,
> >> remove the @cpu_index argument from handler,
> >> rename API as nmi_trigger() (not
> On 20 Mar 2024, at 12:19, Philippe Mathieu-Daudé wrote:
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> On 20/2/24 16:19, Thomas Huth wrote:
>> On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
>>>
On 20/2/24 16:19, Thomas Huth wrote:
On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
Have s390x always deliver NMI to the first CPU,
remove the @cpu_index argument from handler,
rename API as nmi_trigger() (not monitor specific).
Could you please add some rationale here why this is needed
On 20/2/24 16:19, Thomas Huth wrote:
On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
Have s390x always deliver NMI to the first CPU,
remove the @cpu_index argument from handler,
rename API as nmi_trigger() (not monitor specific).
Could you please add some rationale here why this is needed
On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
Have s390x always deliver NMI to the first CPU,
remove the @cpu_index argument from handler,
rename API as nmi_trigger() (not monitor specific).
Could you please add some rationale here why this is needed / desired?
Thanks,
Thomas
Have s390x always deliver NMI to the first CPU,
remove the @cpu_index argument from handler,
rename API as nmi_trigger() (not monitor specific).
Philippe Mathieu-Daudé (4):
hw/nmi: Use object_child_foreach_recursive() in nmi_children()
hw/s390x/virtio-ccw: Always deliver NMI to first CPU
13 matches
Mail list logo
