Regression: drm: Lobotomize set_busid nonsense for !pci drivers (a325725633c2)

[Emil Velikov]

On 3 October 2016 at 13:14, Laszlo Ersek <lersek at redhat.com> wrote:
> On 10/03/16 13:34, Emil Velikov wrote:
>> On 30 September 2016 at 18:26, Laszlo Ersek <lersek at redhat.com> wrote:
>
>>> This setup (modulo the kernel of course) was known to work, but now the
>>> X server actually segfaults (apparently in the
>>> xf86PlatformDeviceCheckBusID() function). Please find the logfile attached.
>>>
>>> (NB: this is unrelated to upstream commit de9ce6757c2e -- which the
>>> pristine FC24 build lacks -- because I don't set AutoAddGPU to "off" --
>>> it is left at its default "on" value.)
>>>
>> Where is this upstream commit again - it shows as unknown for the
>> kernel, xserver and libdrm ?
>
> Apologies, that commit hash belongs to a cherry-picked patch on one of
> my private branches; the original is
>
>   ea91db4b8331 config: fix GPUDevice fail when AutoAddGPU off + BusID
>
>
>> So my theory was a bit off - SetVersion is the one responsible to set
>> the "BusID", as retrieved by drmGetBusID, regardless if drmOpen or
>> open is used.
>>
>> Here's a bit of a brain dump from the other day:
>>
>>  - The commit mentioned
>
> (Here I assume you mean kernel commit
>
>   a325725633c2 drm: Lobotomize set_busid nonsense for !pci drivers
>
> again.)
>
Correct.

>>'affects' the drmSetBusid/DRM_IOCTL_SET_UNIQUE
>> userspace codepaths.
>>  - The latter itself is dri1/legacy (xserver hw/xfree86/dri/) which is
>> not functional for platform devices.
>> The latter of which seems to be the case for virt-gpu based on the
>> kernel module.
>>  - The modesetting driver should/cannot reach the above xserver codepath
>>
>> That said, it seems that (at least some) userspace expects a PCI
>> device despite the kernel module 'advertising' itself as platform one
>> :-\
>>
>> Going through the xserver layers is a bit inspiring I'm wondering if
>> we can not get a strace before/after the xserver commit
>> ca8d88e50310a0d440a127c22a0a383cc149f408 ? It will help us track
>> things a lot quicker/easier.
>
> This commit:
>
>   ca8d88e50310 xfree86: recognize primary BUS_PCI device in
>                xf86IsPrimaryPlatform()
>
> is not relevant when running Xorg on QEMU's "virtio-vga" device, it is
> only relevant when the "virtio-gpu-pci" device is used. Aarch64 guests
> can't have "virtio-vga", only "virgio-gpu-pci", so that commit was
> needed for Aarch64 guests primarily.
>
> In this case however, kernel commit a325725633c2 breaks "virtio-vga" in
> x86_64 guests, both with and without xserver commit ca8d88e50310.
>
> Anyway I'll look into capturing a strace and/or following Xorg with gdb.
>
If the overall case/issue is irrelevant of the xserver commit we can
ignore if for the time being.
In that case can you please get a xserver strace before/after the
offending kernel commit.

Thank you.
Emil