Michael Ellerman writes:
> Michael Roth writes:
>> Quoting Nathan Lynch (2020-08-07 02:05:09)
> ...
>>> wait_for_cpu_stopped() should be able to accommodate a time-based
>>> warning if necessary, but speaking as a likely recipient of any bug
>>> reports that would arise here, I'm not convinced o
Michael Roth writes:
> Quoting Nathan Lynch (2020-08-07 02:05:09)
...
>> wait_for_cpu_stopped() should be able to accommodate a time-based
>> warning if necessary, but speaking as a likely recipient of any bug
>> reports that would arise here, I'm not convinced of the need and I
>> don't know what
Quoting Nathan Lynch (2020-08-07 02:05:09)
> Hi everyone,
>
> Michael Ellerman writes:
> > Greg Kurz writes:
> >> On Tue, 04 Aug 2020 23:35:10 +1000
> >> Michael Ellerman wrote:
> >>> Spinning forever seems like a bad idea, but as has been demonstrated at
> >>> least twice now, continuing when
Hi everyone,
Michael Ellerman writes:
> Greg Kurz writes:
>> On Tue, 04 Aug 2020 23:35:10 +1000
>> Michael Ellerman wrote:
>>> Spinning forever seems like a bad idea, but as has been demonstrated at
>>> least twice now, continuing when we don't know the state of the other
>>> CPU can lead to st
Michael Roth writes:
> Quoting Michael Roth (2020-08-04 23:37:32)
>> Quoting Michael Ellerman (2020-08-04 22:07:08)
>> > Greg Kurz writes:
>> > > On Tue, 04 Aug 2020 23:35:10 +1000
>> > > Michael Ellerman wrote:
>> > >> Spinning forever seems like a bad idea, but as has been demonstrated at
>> >
Quoting Michael Roth (2020-08-05 17:29:28)
> Quoting Michael Roth (2020-08-04 23:37:32)
> > Quoting Michael Ellerman (2020-08-04 22:07:08)
> > > Greg Kurz writes:
> > > > On Tue, 04 Aug 2020 23:35:10 +1000
> > > > Michael Ellerman wrote:
> > > >> Spinning forever seems like a bad idea, but as has
Quoting Michael Roth (2020-08-04 23:37:32)
> Quoting Michael Ellerman (2020-08-04 22:07:08)
> > Greg Kurz writes:
> > > On Tue, 04 Aug 2020 23:35:10 +1000
> > > Michael Ellerman wrote:
> > >> Spinning forever seems like a bad idea, but as has been demonstrated at
> > >> least twice now, continuin
Quoting Michael Ellerman (2020-08-04 22:07:08)
> Greg Kurz writes:
> > On Tue, 04 Aug 2020 23:35:10 +1000
> > Michael Ellerman wrote:
> >> There is a bit of history to this code, but not in a good way :)
> >>
> >> Michael Roth writes:
> >> > For a power9 KVM guest with XIVE enabled, running a t
Michael Ellerman writes:
> Greg Kurz writes:
>> On Tue, 04 Aug 2020 23:35:10 +1000
>> Michael Ellerman wrote:
>>> There is a bit of history to this code, but not in a good way :)
>>>
>>> Michael Roth writes:
>>> > For a power9 KVM guest with XIVE enabled, running a test loop
>>> > where we h
Greg Kurz writes:
> On Tue, 04 Aug 2020 23:35:10 +1000
> Michael Ellerman wrote:
>> There is a bit of history to this code, but not in a good way :)
>>
>> Michael Roth writes:
>> > For a power9 KVM guest with XIVE enabled, running a test loop
>> > where we hotplug 384 vcpus and then unplug them
On Tue, 04 Aug 2020 23:35:10 +1000
Michael Ellerman wrote:
> Hi Mike,
>
> There is a bit of history to this code, but not in a good way :)
>
> Michael Roth writes:
> > For a power9 KVM guest with XIVE enabled, running a test loop
> > where we hotplug 384 vcpus and then unplug them, the followi
Hi Mike,
There is a bit of history to this code, but not in a good way :)
Michael Roth writes:
> For a power9 KVM guest with XIVE enabled, running a test loop
> where we hotplug 384 vcpus and then unplug them, the following traces
> can be seen (generally within a few loops) either from the unpl
For a power9 KVM guest with XIVE enabled, running a test loop
where we hotplug 384 vcpus and then unplug them, the following traces
can be seen (generally within a few loops) either from the unplugged
vcpu:
[ 1767.353447] cpu 65 (hwid 65) Ready to die...
[ 1767.952096] Querying DEAD? cpu 66 (6
13 matches
Mail list logo
