On Wed, 27 May 2020 12:53:30 -0400 Peter Xu <pet...@redhat.com> wrote:
> On Wed, May 27, 2020 at 06:27:38PM +0200, Philippe Mathieu-Daudé wrote: > > On 5/27/20 6:16 PM, Peter Xu wrote: > > > On Wed, May 27, 2020 at 05:53:16PM +0200, Philippe Mathieu-Daudé wrote: > > >>>>> + for (i = 0; i < ARRAY_SIZE(iommu); i++) { > > >>>>> + if (ioctl(container->fd, VFIO_CHECK_EXTENSION, > > >>>>> iommu[i].type)) { > > >>>>> + trace_vfio_get_iommu_type(iommu[i].type, iommu[i].name); > > >>>>> > > >>>> Just wondering why you want to trace the type as you now have the name > > >>>> string. > > >>> > > >>> You are right :) > > >>> > > >>>>> + return iommu[i].type; > > >>>>> } > > >>>>> } > > >>>>> + trace_vfio_get_iommu_type(-1, "Not available or not supported"); > > >>>>> > > >>>> nit: from a debugging pov, this may be not needed as > > >>>> vfio_get_group/vfio_connect_container() fails and this leads to an > > >>>> error > > >>>> output. > > >> > > >> But you can reach this for example using No-IOMMU. If you don't mind, I > > >> find having this information in the trace log clearer. > > > > > > I kinda agree with Eric - AFAICT QEMU vfio-pci don't work with no-iommu, > > > then > > > it seems meaningless to trace it... > > > > > > I'm not sure whether this trace is extremely helpful because syscalls > > > like this > > > could be easily traced by things like strace or bpftrace as general tools > > > (and > > > this information should be a one-time thing rather than dynamically > > > changing), > > > no strong opinion though. Also, if we want to dump something, maybe it's > > > better to do in vfio_init_container() after vfio_get_iommu_type() > > > succeeded, so > > > we dump which container is enabled with what type of iommu. > > > > OK. I'm a recent VFIO user so maybe I am not using the good information. > > > > This trace helps me while working on a new device feature, I didn't > > thought about gathering it in a production because there I'd expect > > things to work. > > > > Now in my case what I want is to know is if I'm using a v1 or v2 type. > > Maybe this information is already available in /proc or /sys and we > > don't need this patch... > > I don't know such /proc or /sys, so maybe it's still useful. I guess Alex > would > have the best judgement. The strace/bpftrace things are not really reasons I > found to nak this patch, but just something I thought first that could be > easier when any of us wants to peak at those information, probably something > just FYI. :-) Personally, I find traces to be quite handy, and it's nice if you can just enable more of them if they are in your debugging workflow anyway. Probably boils down to a matter of preference :)