On 10/1/21 12:38, Greg Kurz wrote:
On Fri, 1 Oct 2021 11:59:45 +0200
Cédric Le Goater wrote:
Maybe it would be simpler to call xive_source_is_initialized() instead of
xive_eas_is_valid() in cases like this, e.g. hcall code since it is shared
between emulation and KVM ?
Yes but we need a bett
On Fri, 1 Oct 2021 11:59:45 +0200
Cédric Le Goater wrote:
> >>> Maybe it would be simpler to call xive_source_is_initialized() instead of
> >>> xive_eas_is_valid() in cases like this, e.g. hcall code since it is shared
> >>> between emulation and KVM ?
> >>
> >> Yes but we need a better check tha
Maybe it would be simpler to call xive_source_is_initialized() instead of
xive_eas_is_valid() in cases like this, e.g. hcall code since it is shared
between emulation and KVM ?
Yes but we need a better check than :
if (lisn < SPAPR_XIRQ_BASE) {
return !!xive_get_field64(EAS_END_
On Mon, 27 Sep 2021 18:50:40 +0200
Cédric Le Goater wrote:
> On 9/24/21 19:13, Greg Kurz wrote:
> > On Fri, 24 Sep 2021 16:58:00 +0200
> > Cédric Le Goater wrote:
> >
> >> [ ... ]
> >>
> The changes only impact KVM support since we are deferring the IRQ
> initialization at the KVM lev
On 9/24/21 19:13, Greg Kurz wrote:
On Fri, 24 Sep 2021 16:58:00 +0200
Cédric Le Goater wrote:
[ ... ]
The changes only impact KVM support since we are deferring the IRQ
initialization at the KVM level. What we have to be careful about is not
accessing an ESB page of an interrupt that would n
On Fri, 24 Sep 2021 16:58:00 +0200
Cédric Le Goater wrote:
> [ ... ]
>
> >> The changes only impact KVM support since we are deferring the IRQ
> >> initialization at the KVM level. What we have to be careful about is not
> >> accessing an ESB page of an interrupt that would not have been initili
[ ... ]
The changes only impact KVM support since we are deferring the IRQ
initialization at the KVM level. What we have to be careful about is not
accessing an ESB page of an interrupt that would not have been initiliazed
in the KVM device, else QEMU gets a sigbus.
Ok, so this is just needed
On Fri, 24 Sep 2021 14:40:24 +0200
Cédric Le Goater wrote:
> On 9/23/21 11:12, Greg Kurz wrote:
> > On Wed, 22 Sep 2021 16:41:20 +0200
> > Cédric Le Goater wrote:
> >
> >> When QEMU switches to the XIVE interrupt mode, it creates all possible
> >> guest interrupts at the level of the KVM device
On 9/23/21 11:12, Greg Kurz wrote:
On Wed, 22 Sep 2021 16:41:20 +0200
Cédric Le Goater wrote:
When QEMU switches to the XIVE interrupt mode, it creates all possible
guest interrupts at the level of the KVM device. These interrupts are
backed by real HW interrupts from the IPI interrupt pool of
On Wed, 22 Sep 2021 16:41:20 +0200
Cédric Le Goater wrote:
> When QEMU switches to the XIVE interrupt mode, it creates all possible
> 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.
>
> Cur
When QEMU switches to the XIVE interrupt mode, it creates all possible
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 main thread, which results in
allocati
11 matches
Mail list logo
