Re: [Qemu-devel] [PATCH for-1.5 0/9] Disable expensive QOM cast debugging for official releases

[Anthony Liguori]

Paolo Bonzini <address@hidden> writes:

> Il 10/05/2013 16:39, Anthony Liguori ha scritto:
>> I just oppose the notion of disabling casts and *especially* only
>> disabling casts for official builds.
>
> This actually happens all the time.  Exactly this kind of type-safe cast
> is disabled in releases of GCC, but enabled when building from svn trunk.

Let's assume for a moment that you are right and this behavior is what
we should have.  Let's also assume there is a real regression here
which has yet to have been established.

As soon as we open up 1.6 for development, we face an immediate
regression in performance.  So we need to fix the real problem here
anyway.

I strongly suspect that if there is a problem, that optimizing
leaf/concrete casts will take care of it.  Otherwise, a small lookup
cache ought to do the trick too.  We can even use pointer comparisons
for the lookup cache which should make it extremely cheap.

Disabling casts doesn't give us a long term fix.  One of the solutions
above does and patches also exist.

So first, let's establish if there really is a performance issue here
and if so, let's find a long term solution.

Let's independently evaluate your proposal for 1.6.  You may in fact be
right that it's the right thing to do long term, but I'm quite confident
that it's not the right solution to the potential issue here.

> I have hardly seen any of these failures _during development_, much less
> on a release.

It's the most common failure that I catch in my own testing.  Most often
around hotplug which tends to break the most.

Of course, these changes never make it into the tree which is an
indication that the mechanism works very well :-)

>  I appreciate the advantage of type-safe casts, but in
> QEMU they are a solution in search of a problem.  They are cheap to
> implement (though not that cheap to execute ;)) so it's perfectly fine
> to have them, but they are not _needed_; disabling them is anyway a good
> build-time option to have.

Note that the cast macros are a big improvement in code readability.
The only real replacement would be static casts which would downgrade
safety.

If you want to debate the merits of the safety, that's fine.

> Type-safe casts make sense in GTK+/GObject where: 1) type-safe casts
> return NULL and log a "critical" error, they do not abort;  2) all
> functions fail with another "critical" error if they are passed NULL.
> We do neither, so we're just trading a crash now for a crash very soon
> after (our call stacks tend to be relatively shallow, with some
> exceptions such as the block layer).

The big assumption here is that dereference a NULL results in
predictable failure.  This is not always the case and can lead to
security vulnerabilities.

> Also, in GTK+/GObject the code paths are unpredictable because they
> depend on user interaction, and a crash can lead to data loss.  By
> contrast, in QEMU most of the code is hardly ever run, and the possible
> paths are very few because driver writers tend to use always the same
> path.  The day someone is bringing up a new guest OS and encounters such
> a crash, we'll tell them to either build from git, or to use
> --enable-qom-cast-debug.
>
> I'm sure it will be a long time before that happens...

If you are concerned about the performance, provide a concrete example
of poor performance and I will fix it.

If we find one that is unfixable, then we should consider your
proposal.

Regards,

Anthony Liguori

>
> Paolo
>
>> Regards,
>> 
>> Anthony Liguori
>> 
>>>> Either way, it would be nice to see the call sites of those
>>>> most-impacting dynamic casts! So far I held back my APIC RFC since I'm
>>>> not sure how to reproducibly profile things.
>>>
>>> It's interrupts (both sending and returning from them).
>>>
>>> Paolo
>> 
>> 
>>