On Mon, May 06, 2019 at 11:13:28AM -0500, Paolo Bonzini wrote:
> On 05/05/19 04:06, Peter Xu wrote:
> >> I wonder if it's possible to untangle this and make the irqchip
> >> option stop affecting guest ABI on 4.1+ machine-types? This way
> >> QEMU could choose smarter defaults in the future
On 03/05/19 15:00, Michael S. Tsirkin wrote:
> On Mon, Apr 29, 2019 at 11:55:56AM -0300, Eduardo Habkost wrote:
>> irqchip=split and irqchip=kernel aren't guest ABI compatible, are
>> they?
>
> Can you remind me why they aren't?
They are compatible if the userspace IOAPIC is configured with
On 05/05/19 04:06, Peter Xu wrote:
>> I wonder if it's possible to untangle this and make the irqchip
>> option stop affecting guest ABI on 4.1+ machine-types? This way
>> QEMU could choose smarter defaults in the future without the
>> compatibility code hassle.
> Hi, Eduardo,
>
> Do you mean to
On Fri, May 03, 2019 at 03:42:06PM -0300, Eduardo Habkost wrote:
> On Mon, Apr 29, 2019 at 09:22:12AM -0600, Alex Williamson wrote:
> [...]
> > > > What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip
> > > > as the Q35 default? I can't see that simply switching to current QEMU
>
On Fri, May 03, 2019 at 04:00:33PM -0400, Michael S. Tsirkin wrote:
> On Mon, Apr 29, 2019 at 11:55:56AM -0300, Eduardo Habkost wrote:
> > irqchip=split and irqchip=kernel aren't guest ABI compatible, are
> > they?
>
> Can you remind me why they aren't?
We have the code introduced by patch 3/3
On Mon, Apr 29, 2019 at 11:55:56AM -0300, Eduardo Habkost wrote:
> irqchip=split and irqchip=kernel aren't guest ABI compatible, are
> they?
Can you remind me why they aren't?
> --
> Eduardo
On Mon, Apr 29, 2019 at 09:22:12AM -0600, Alex Williamson wrote:
[...]
> > > What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip
> > > as the Q35 default? I can't see that simply switching to current QEMU
> > > handling is a viable option for performance? What about 4.1? We
On Wed, 1 May 2019 01:09:48 +0200
Paolo Bonzini wrote:
> On 01/05/19 01:01, Alex Williamson wrote:
> > Poking at this a bit, we can add kvm_irqchip_is_split() to the set of
> > things we test for in hw/vfio/pci.c:vfio_intx_enable_kvm() to avoid the
> > KVM INTx bypass when using split IRQ chip.
On 01/05/19 01:01, Alex Williamson wrote:
> Poking at this a bit, we can add kvm_irqchip_is_split() to the set of
> things we test for in hw/vfio/pci.c:vfio_intx_enable_kvm() to avoid the
> KVM INTx bypass when using split IRQ chip.
Yes, this should be enough.
> The only way I can get the
On Mon, 29 Apr 2019 08:21:06 -0600
Alex Williamson wrote:
> On Sat, 27 Apr 2019 10:09:51 +0200
> Paolo Bonzini wrote:
>
> > On 27/04/19 07:29, Paolo Bonzini wrote:
> > >
> > >>> In my testing it looks like KVM advertises supporting the KVM_IRQFD
> > >>> resample feature, but vfio never
On Mon, 29 Apr 2019 11:55:56 -0300
Eduardo Habkost wrote:
> On Mon, Apr 29, 2019 at 08:21:06AM -0600, Alex Williamson wrote:
> > On Sat, 27 Apr 2019 10:09:51 +0200
> > Paolo Bonzini wrote:
> >
> > > On 27/04/19 07:29, Paolo Bonzini wrote:
> > > >
> > > >>> In my testing it looks like
On Mon, Apr 29, 2019 at 08:21:06AM -0600, Alex Williamson wrote:
> On Sat, 27 Apr 2019 10:09:51 +0200
> Paolo Bonzini wrote:
>
> > On 27/04/19 07:29, Paolo Bonzini wrote:
> > >
> > >>> In my testing it looks like KVM advertises supporting the KVM_IRQFD
> > >>> resample feature, but vfio never
On Sat, 27 Apr 2019 10:09:51 +0200
Paolo Bonzini wrote:
> On 27/04/19 07:29, Paolo Bonzini wrote:
> >
> >>> In my testing it looks like KVM advertises supporting the KVM_IRQFD
> >>> resample feature, but vfio never gets the unmask notification, so the
> >>> device remains with DisINTx set and
On 27/04/19 07:29, Paolo Bonzini wrote:
>
>>> In my testing it looks like KVM advertises supporting the KVM_IRQFD
>>> resample feature, but vfio never gets the unmask notification, so the
>>> device remains with DisINTx set and no further interrupts are
>>> generated. Do we expect KVM's IRQFD
> > In my testing it looks like KVM advertises supporting the KVM_IRQFD
> > resample feature, but vfio never gets the unmask notification, so the
> > device remains with DisINTx set and no further interrupts are
> > generated. Do we expect KVM's IRQFD with resampler to work in the
> > split IRQ
On Fri, 26 Apr 2019 13:27:44 -0600
Alex Williamson wrote:
> On Thu, 20 Dec 2018 13:40:35 +0800
> Peter Xu wrote:
>
> > Starting from QEMU 4.0, let's specify "split" as the default value for
> > kernel-irqchip.
> >
> > So for QEMU>=4.0 we'll have: allowed=Y,required=N,split=Y
> >for
On Thu, 20 Dec 2018 13:40:35 +0800
Peter Xu wrote:
> Starting from QEMU 4.0, let's specify "split" as the default value for
> kernel-irqchip.
>
> So for QEMU>=4.0 we'll have: allowed=Y,required=N,split=Y
>for QEMU<=3.1 we'll have: allowed=Y,required=N,split=N
>(omitting all the
On Thu, Dec 20, 2018 at 01:40:35PM +0800, Peter Xu wrote:
> Starting from QEMU 4.0, let's specify "split" as the default value for
> kernel-irqchip.
>
> So for QEMU>=4.0 we'll have: allowed=Y,required=N,split=Y
>for QEMU<=3.1 we'll have: allowed=Y,required=N,split=N
>(omitting all the
Starting from QEMU 4.0, let's specify "split" as the default value for
kernel-irqchip.
So for QEMU>=4.0 we'll have: allowed=Y,required=N,split=Y
for QEMU<=3.1 we'll have: allowed=Y,required=N,split=N
(omitting all the "kernel_irqchip_" prefix)
Note that this will let the default q35
19 matches
Mail list logo
