[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <726db8fdf6c7fc271a825badbf1b07a5eebe6d36.camel@sipsolutions.net>
Date: Sun, 12 Jun 2022 10:58:20 +0200
From: Johannes Berg <johannes@...solutions.net>
To: "Michael S. Tsirkin" <mst@...hat.com>,
Vincent Whitchurch <vincent.whitchurch@...s.com>
Cc: Richard Weinberger <richard@....at>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
kernel@...s.com, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Jason Wang <jasowang@...hat.com>, linux-um@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] um: virt-pci: set device ready in probe()
On Fri, 2022-06-10 at 20:34 -0400, Michael S. Tsirkin wrote:
>
> Also fixes this commit:
>
> commit 68f5d3f3b6543266b29e047cfaf9842333019b4c
> Author: Johannes Berg <johannes.berg@...el.com>
> Date: Fri Mar 5 13:19:58 2021 +0100
>
> um: add PCI over virtio emulation driver
Hm, why? It worked before the harden change.
> BTW Johannes I think you need to spec this device and get
> an ID - what's the plan for that? Current hack of punting
> this to userspace isn't really any good long term.
Yeah, agree, it dropped off my radar (and the process is a bit
cumbersome IMHO).
But I'm not quite sure what you mean wrt. "punting to userspace", here
in the virt-pci code I'm punting to the Kconfig :-)
Did you just mix that up, or was there some additional userspace thing
you're thinking of?
The only userspace thing I can think of it is in virtio_uml where you
have the ID on the command-line, but that's because it implements the
virtio device bus over vhost-user which doesn't have ID discoverability
in the protocol. That could also be fixed I guess, but it's a bit of a
chicken & egg problem, if you don't have the ID and discovering it were
not supported, you'd end up with an unusable device unless you specified
the ID, in which case you don't need to discover it...
johannes
Powered by blists - more mailing lists