All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>,
	Richard Weinberger <richard@nod.at>,
	Anton Ivanov <anton.ivanov@cambridgegreys.com>,
	kernel@axis.com, Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	Jason Wang <jasowang@redhat.com>,
	linux-um@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] um: virt-pci: set device ready in probe()
Date: Sun, 12 Jun 2022 10:08:17 -0400	[thread overview]
Message-ID: <20220612065324-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <726db8fdf6c7fc271a825badbf1b07a5eebe6d36.camel@sipsolutions.net>

On Sun, Jun 12, 2022 at 10:58:20AM +0200, Johannes Berg wrote:
> On Fri, 2022-06-10 at 20:34 -0400, Michael S. Tsirkin wrote:
> > 
> > Also fixes this commit:
> > 
> > commit 68f5d3f3b6543266b29e047cfaf9842333019b4c
> > Author: Johannes Berg <johannes.berg@intel.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.

Worked on a specific hypervisor. It was out of spec though.

> > 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).

Hmm.

So right the recommended way is:
post patch
open github issue
send an email requesting vote

I guess we can switch request for vote to the github issue
to streamline this a bit - do you think that will help?




> 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?

Right, I meant "punting it to the user".

> 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


So, please start by reserving an id.

-- 
MST


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>,
	Richard Weinberger <richard@nod.at>,
	Anton Ivanov <anton.ivanov@cambridgegreys.com>,
	kernel@axis.com, Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	Jason Wang <jasowang@redhat.com>,
	linux-um@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] um: virt-pci: set device ready in probe()
Date: Sun, 12 Jun 2022 10:08:17 -0400	[thread overview]
Message-ID: <20220612065324-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <726db8fdf6c7fc271a825badbf1b07a5eebe6d36.camel@sipsolutions.net>

On Sun, Jun 12, 2022 at 10:58:20AM +0200, Johannes Berg wrote:
> On Fri, 2022-06-10 at 20:34 -0400, Michael S. Tsirkin wrote:
> > 
> > Also fixes this commit:
> > 
> > commit 68f5d3f3b6543266b29e047cfaf9842333019b4c
> > Author: Johannes Berg <johannes.berg@intel.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.

Worked on a specific hypervisor. It was out of spec though.

> > 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).

Hmm.

So right the recommended way is:
post patch
open github issue
send an email requesting vote

I guess we can switch request for vote to the github issue
to streamline this a bit - do you think that will help?




> 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?

Right, I meant "punting it to the user".

> 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


So, please start by reserving an id.

-- 
MST


  reply	other threads:[~2022-06-12 14:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 15:12 [PATCH] um: virt-pci: set device ready in probe() Vincent Whitchurch
2022-06-10 15:12 ` Vincent Whitchurch
2022-06-10 19:36 ` Johannes Berg
2022-06-10 19:36   ` Johannes Berg
2022-06-11  0:34 ` Michael S. Tsirkin
2022-06-11  0:34   ` Michael S. Tsirkin
2022-06-12  8:58   ` Johannes Berg
2022-06-12  8:58     ` Johannes Berg
2022-06-12 14:08     ` Michael S. Tsirkin [this message]
2022-06-12 14:08       ` Michael S. Tsirkin
2022-06-13  6:50   ` Vincent Whitchurch
2022-06-13  6:50     ` Vincent Whitchurch
2022-06-13  6:58 ` Jason Wang
2022-06-13  6:58   ` Jason Wang
2022-06-13  7:25   ` Michael S. Tsirkin
2022-06-13  7:25     ` Michael S. Tsirkin
2022-06-16 10:40   ` Vincent Whitchurch
2022-06-16 10:40     ` Vincent Whitchurch

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=20220612065324-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=jasowang@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=kernel@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=vincent.whitchurch@axis.com \
    --cc=xuanzhuo@linux.alibaba.com \
    /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.