From: Peter Xu <peterx@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Fabiano Rosas" <farosas@suse.de>,
"Juraj Marcin" <jmarcin@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Cédric Le Goater" <clg@redhat.com>,
"John Snow" <jsnow@redhat.com>
Subject: Re: [PATCH 5/5] qom: Make container_get() strict to always walk or return container
Date: Wed, 20 Nov 2024 11:24:19 -0500 [thread overview]
Message-ID: <Zz4NM0MKErNHZcs_@x1n> (raw)
In-Reply-To: <CABgObfbXuiqw01mzVLZEgw-o_tdbf83QzYugq7oL4g7TFVV_yg@mail.gmail.com>
On Wed, Nov 20, 2024 at 12:45:19PM +0100, Paolo Bonzini wrote:
> Il mar 19 nov 2024, 22:43 Peter Xu <peterx@redhat.com> ha scritto:
>
> > > The easiest way to check is probably to print the type of every
> > successful
> > > object_dynamic_cast and object_class_dynamic_cast. I suspect the result
> > > will be virtio-blk-device and/or scsi-hd, but maybe those already do an
> > > unsafe cast (pointer type cast) instead of object_dynamic_cast.
> >
> > Yes, it sounds more reasonable to me to optimize specific call sites so far
> > rather than provides something generic.
>
> Though it could still be a
> > generic API so that devices can opt-in.
>
>
> One of the things that I am excited about for Rust is checking at compile
> time whether a cast is to a superclass, which makes it safe automatically.
I see. However looks like it doesn't easily apply to the ahci example
below, where it could conditionally fail the cast (and where I got it
wrong..)?
>
> > I can give it some measurement if there is, otherwise I'm
> > > > guessing whatever changes could fall into the noise.
> > >
> > >
> > > Yes, probably. At most you can identify if there any heavy places out of
> > > the 34000 calls, and see if they can use an unsafe cast.
> >
> > I can still trivially do this.
> >
> > I traced qemu using bpf
>
>
> Nice! I want to know more. :))
I also only learned it yesterday, where I only used to use k*probes
previously. :-) That's:
$ cat qemu.bpf
uprobe:/home/peterx/git/qemu/bin/qemu-system-x86_64:object_class_dynamic_cast
{
@out[ustack()]++;
}
$ sudo bpftrace --usdt-file-activation ./qemu.bpf
>
> > and interestingly in my case close to half (over
> > 10000+) of the calls are about ahci_irq_lower() from different higher level
> > stack (yeah I used IDE in my setup.. with a split irqchi..), where it has:
> >
> > PCIDevice *pci_dev = (PCIDevice *)
> > object_dynamic_cast(OBJECT(dev_state),
> >
> > TYPE_PCI_DEVICE);
> >
> > So IIUC that can be open to a unsafe cast too
>
>
> Hmm no it can't because there's also sysbus AHCI. The fix would be to add
> an AHCIClass and make irq toggling into a method there
Yep, I overlooked the lines of code later.. :(
>
> but considering IDE is ODD FIXES stage, I'm not sure if I should send a
> > patch at all. However I copied John regardless.
> >
>
> Well, MAINTAINERS only says the kind of work that the maintainer is doing,
> you can always do more. However it seems like not a small amount, so maybe
> adding a comment is enough if somebody else wants to do it?
Can do.
--
Peter Xu
next prev parent reply other threads:[~2024-11-20 16:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 22:13 [PATCH 0/5] QOM: Enforce container_get() to operate on containers only Peter Xu
2024-11-18 22:13 ` [PATCH 1/5] qom: Add TYPE_CONTAINER macro Peter Xu
2024-11-19 9:42 ` Daniel P. Berrangé
2024-11-19 19:52 ` Peter Xu
2024-11-18 22:13 ` [PATCH 2/5] ppc/e500: Avoid abuse of container_get() Peter Xu
2024-11-18 22:13 ` [PATCH 3/5] qdev: Make device_set_realized() always safe in tests Peter Xu
2024-11-19 9:46 ` Daniel P. Berrangé
2024-11-19 20:14 ` Peter Xu
2024-11-18 22:13 ` [PATCH 4/5] qdev: Make qdev_get_machine() not use container_get() Peter Xu
2024-11-18 22:13 ` [PATCH 5/5] qom: Make container_get() strict to always walk or return container Peter Xu
2024-11-18 23:06 ` Peter Xu
2024-11-19 8:09 ` Paolo Bonzini
2024-11-19 20:06 ` Peter Xu
2024-11-19 20:30 ` Paolo Bonzini
2024-11-19 21:43 ` Peter Xu
2024-11-20 11:45 ` Paolo Bonzini
2024-11-20 16:24 ` Peter Xu [this message]
2024-11-19 10:03 ` Daniel P. Berrangé
2024-11-19 20:25 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zz4NM0MKErNHZcs_@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=clg@redhat.com \
--cc=eduardo@habkost.net \
--cc=farosas@suse.de \
--cc=jmarcin@redhat.com \
--cc=jsnow@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.