Re: [Qemu-devel] [PATCH] vfio-pci: Add KVM INTx acceleration

["Michael S. Tsirkin" <mst@redhat.com>]

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