On 8/20/20 2:42 AM, David Gibson wrote:
> On Sun, Aug 16, 2020 at 03:38:20PM +0200, Cédric Le Goater wrote:
>> On 8/16/20 6:30 AM, David Gibson wrote:
>>> On Fri, Aug 14, 2020 at 05:08:13PM +0200, Cédric Le Goater wrote:
This works as expected with a 128 vCPUs guest with pinned vcpus. The
On Sun, Aug 16, 2020 at 03:38:20PM +0200, Cédric Le Goater wrote:
> On 8/16/20 6:30 AM, David Gibson wrote:
> > On Fri, Aug 14, 2020 at 05:08:13PM +0200, Cédric Le Goater wrote:
> >>
> >> This works as expected with a 128 vCPUs guest with pinned vcpus. The
> >> first 64 IPIs are allocated on the fi
On 8/16/20 6:30 AM, David Gibson wrote:
> On Fri, Aug 14, 2020 at 05:08:13PM +0200, Cédric Le Goater wrote:
>>
>> This works as expected with a 128 vCPUs guest with pinned vcpus. The
>> first 64 IPIs are allocated on the first chip and the remaining 64
>> on the second chip.
>>
>> Still, this is mo
On Fri, Aug 14, 2020 at 05:08:13PM +0200, Cédric Le Goater wrote:
>
> This works as expected with a 128 vCPUs guest with pinned vcpus. The
> first 64 IPIs are allocated on the first chip and the remaining 64
> on the second chip.
>
> Still, this is more an RFC. We have time before the end of the
This works as expected with a 128 vCPUs guest with pinned vcpus. The
first 64 IPIs are allocated on the first chip and the remaining 64
on the second chip.
Still, this is more an RFC. We have time before the end of the merge
window.
Thanks,
C.
On 8/14/20 5:03 PM, Cédric Le Goater wrote:
>
When QEMU switches to the XIVE interrupt mode, it performs a
kvmppc_xive_source_reset() which creates all the guest interrupts at
the level of the KVM device. These interrupts are backed by real HW
interrupts from the IPI interrupt pool of the XIVE controller.
Currently, this is done from the QEMU
