From: Stefan Hajnoczi <stefanha@gmail.com> To: Johannes Berg <johannes@sipsolutions.net> Cc: ido@wizery.com, linux-um@lists.infradead.org, qemu-devel <qemu-devel@nongnu.org>, Linux Virtualization <virtualization@lists.linux-foundation.org> Subject: Re: [Qemu-devel] custom virt-io support (in user-mode-linux) Date: Thu, 23 May 2019 15:41:18 +0100 [thread overview] Message-ID: <CAJSP0QWSZXT3OJAc=abagD40xZ7DWWrcP_+AwVBuqQyQNgaOEg@mail.gmail.com> (raw) In-Reply-To: <41d64b8971a097d1568f947517b45d09c156ccc8.camel@sipsolutions.net> On Thu, May 23, 2019 at 3:25 PM Johannes Berg <johannes@sipsolutions.net> wrote: > Not sure I understand why there's all this stuff about multiple FDs, > once you have access to the guest's memory, why do you still need a > second (or more) FDs? The memory regions could be different files (maybe additional RAM was hotplugged later). > Also, not sure I understand how the client is started? The vhost-user device backend can be launched before QEMU. QEMU is started with the UNIX domain socket path so it can connect. QEMU itself doesn't fork+exec the vhost-user device backend. It's expected that the user or the management stack has already launched the vhost-user device backend. > Once we have a connection, I guess as a client I'd at the very least > have to handle > * VHOST_USER_GET_FEATURES and reply with the features, obviously, which > is in this case just VHOST_USER_F_PROTOCOL_FEATURES? > > * VHOST_USER_SET_FEATURES - not sure, what would that do? the master > sends VHOST_USER_GET_PROTOCOL_FEATURES which is with this feature > bit? Especially since it says: "Slave that reported > VHOST_USER_F_PROTOCOL_FEATURES must support this message even before > VHOST_USER_SET_FEATURES was called." > > * VHOST_USER_GET_PROTOCOL_FEATURES - looking at the list, most I don't > really need here, but OK > > * VHOST_USER_SET_OWNER - ?? > > * VHOST_USER_RESET_OWNER - ignore > > * VHOST_USER_SET_MEM_TABLE - store the data/FDs for later use, I guess > > * VHOST_USER_SET_VRING_NUM - store the data for later use > * VHOST_USER_SET_VRING_ADDR - dito > * VHOST_USER_SET_VRING_BASE - dito > * VHOST_USER_SET_VRING_KICK - start epoll on the FD (assuming there is > one, give up if not?) - well, if ring is > enabled? > * VHOST_USER_SET_VRING_CALL - ... > > I guess there might be better documentation on the ioctl interfaces? > > > Do you know if there's a sample client/server somewhere? See contrib/libvhost-user in the QEMU source tree as well as the vhost-user-blk and vhost-user-scsi examples in the contrib/ directory. Stefan
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Hajnoczi <stefanha@gmail.com> To: Johannes Berg <johannes@sipsolutions.net> Cc: ido@wizery.com, linux-um@lists.infradead.org, qemu-devel <qemu-devel@nongnu.org>, Linux Virtualization <virtualization@lists.linux-foundation.org> Subject: Re: [Qemu-devel] custom virt-io support (in user-mode-linux) Date: Thu, 23 May 2019 15:41:18 +0100 [thread overview] Message-ID: <CAJSP0QWSZXT3OJAc=abagD40xZ7DWWrcP_+AwVBuqQyQNgaOEg@mail.gmail.com> (raw) In-Reply-To: <41d64b8971a097d1568f947517b45d09c156ccc8.camel@sipsolutions.net> On Thu, May 23, 2019 at 3:25 PM Johannes Berg <johannes@sipsolutions.net> wrote: > Not sure I understand why there's all this stuff about multiple FDs, > once you have access to the guest's memory, why do you still need a > second (or more) FDs? The memory regions could be different files (maybe additional RAM was hotplugged later). > Also, not sure I understand how the client is started? The vhost-user device backend can be launched before QEMU. QEMU is started with the UNIX domain socket path so it can connect. QEMU itself doesn't fork+exec the vhost-user device backend. It's expected that the user or the management stack has already launched the vhost-user device backend. > Once we have a connection, I guess as a client I'd at the very least > have to handle > * VHOST_USER_GET_FEATURES and reply with the features, obviously, which > is in this case just VHOST_USER_F_PROTOCOL_FEATURES? > > * VHOST_USER_SET_FEATURES - not sure, what would that do? the master > sends VHOST_USER_GET_PROTOCOL_FEATURES which is with this feature > bit? Especially since it says: "Slave that reported > VHOST_USER_F_PROTOCOL_FEATURES must support this message even before > VHOST_USER_SET_FEATURES was called." > > * VHOST_USER_GET_PROTOCOL_FEATURES - looking at the list, most I don't > really need here, but OK > > * VHOST_USER_SET_OWNER - ?? > > * VHOST_USER_RESET_OWNER - ignore > > * VHOST_USER_SET_MEM_TABLE - store the data/FDs for later use, I guess > > * VHOST_USER_SET_VRING_NUM - store the data for later use > * VHOST_USER_SET_VRING_ADDR - dito > * VHOST_USER_SET_VRING_BASE - dito > * VHOST_USER_SET_VRING_KICK - start epoll on the FD (assuming there is > one, give up if not?) - well, if ring is > enabled? > * VHOST_USER_SET_VRING_CALL - ... > > I guess there might be better documentation on the ioctl interfaces? > > > Do you know if there's a sample client/server somewhere? See contrib/libvhost-user in the QEMU source tree as well as the vhost-user-blk and vhost-user-scsi examples in the contrib/ directory. Stefan _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2019-05-23 14:42 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-22 13:02 [Qemu-devel] custom virt-io support (in user-mode-linux) Johannes Berg 2019-05-22 13:02 ` Johannes Berg 2019-05-22 13:28 ` Anton Ivanov 2019-05-22 13:28 ` [Qemu-devel] " Anton Ivanov 2019-05-22 13:28 ` Anton Ivanov 2019-05-22 13:46 ` [Qemu-devel] " Johannes Berg 2019-05-22 13:46 ` Johannes Berg 2019-05-22 13:46 ` Johannes Berg 2019-05-22 14:00 ` [Qemu-devel] " Anton Ivanov 2019-05-22 14:00 ` Anton Ivanov 2019-05-22 14:00 ` Anton Ivanov 2019-05-23 11:59 ` [Qemu-devel] " Stefan Hajnoczi 2019-05-23 11:59 ` Stefan Hajnoczi 2019-05-23 11:59 ` Stefan Hajnoczi 2019-05-23 14:25 ` Johannes Berg 2019-05-23 14:25 ` Johannes Berg 2019-05-23 14:41 ` Stefan Hajnoczi [this message] 2019-05-23 14:41 ` Stefan Hajnoczi 2019-05-24 9:54 ` Johannes Berg 2019-05-24 9:54 ` Johannes Berg
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='CAJSP0QWSZXT3OJAc=abagD40xZ7DWWrcP_+AwVBuqQyQNgaOEg@mail.gmail.com' \ --to=stefanha@gmail.com \ --cc=ido@wizery.com \ --cc=johannes@sipsolutions.net \ --cc=linux-um@lists.infradead.org \ --cc=qemu-devel@nongnu.org \ --cc=virtualization@lists.linux-foundation.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: linkBe 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.