[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration |
Date: |
Tue, 16 Oct 2012 19:34:15 +0200 |
On Tue, Oct 16, 2012 at 10:49:38AM -0600, Alex Williamson wrote:
> On Tue, 2012-10-16 at 17:23 +0200, Michael S. Tsirkin wrote:
> > On Tue, Oct 16, 2012 at 09:13:15AM -0600, Alex Williamson wrote:
> > > > There's no chance we ship e.g. q35 by mistake without this API: since
> > > > there is no way this specific assert can be missed in even basic
> > > > testing:
> > > >
> > > > So I see it differently:
> > > >
> > > > As coded here:
> > > > chipset authors get lazy and do not implement API.
> > > > bad performance for all users.
> > > >
> > > > With assert:
> > > > chipset authors implement necessary API.
> > > > good performance for all users.
> > >
> > > I prefer a carrot, not a whip. Thanks,
> > >
> > > Alex
> > >
> >
> > It's not just that.
> > Problem is performance testing/fixing is hard.
>
> Getting an error_report from the driver saying it's using a slow path
> and why makes that significantly easier.
>
> > Catching and fixing asserts is easy.
>
> Easy for who? The user trying to test a feature? Probably not. Me,
> who may not have access to the chipset documentation or understand the
> platform? Maybe, maybe not.
>
> > So working around buggy qemu code really backfires
> > as it reverses the motivation for writing well performing
> > code. History proves me right: for each API change where
> > we implemented a fallback old code stayed around for years.
>
> Does that necessarily mean it was wrong? How many of those API changes
> added new features that may have been abandoned if the developer was
> required to make sweeping changes to get their code accepted? If not
> abandoned, how much delayed? How many land mines might we have in the
> code for changes that were done incorrectly or missed? I don't
> understand why adding robustness to the API is such a contentious point,
> but it's your prerogative, just as it's mine to avoid using that API
> arbitrarily. Thanks,
>
> Alex
Yea. All I say is, I intend to fix things so you don't need
to probe for this API. I think it does not make sense to
add a temporary API as a stopgap for this since it will solve no
actual problem. If e.g. Jason finds it hard to add this to
q35, we could add a stopgap solution for vfio.
--
MST
- [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Alex Williamson, 2012/10/15
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Michael S. Tsirkin, 2012/10/16
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Alex Williamson, 2012/10/16
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Michael S. Tsirkin, 2012/10/16
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Alex Williamson, 2012/10/16
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Michael S. Tsirkin, 2012/10/16
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Alex Williamson, 2012/10/16
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Michael S. Tsirkin, 2012/10/16
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration, Alex Williamson, 2012/10/16
- Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration,
Michael S. Tsirkin <=