From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eugenio Perez Martin <eperezma@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, Gautam Dawar <gdawar@xilinx.com>,
Parav Pandit <parav@mellanox.com>,
Zhu Lingshan <lingshan.zhu@intel.com>, Cindy Lu <lulu@redhat.com>,
longpeng2@huawei.com, Eli Cohen <eli@mellanox.com>,
alvaro.karsz@solid-run.com, Lei Yang <leiyang@redhat.com>,
Laurent Vivier <lvivier@redhat.com>
Subject: Re: [PATCH] vhost: accept VIRTIO_F_ORDER_PLATFORM as a valid SVQ feature
Date: Thu, 2 Mar 2023 06:43:29 -0500 [thread overview]
Message-ID: <20230302064234-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAJaqyWfpbeoLfe1-GcoR=rtJMg1DGezMe8pjSNPQjBG4BzqMrA@mail.gmail.com>
On Thu, Mar 02, 2023 at 12:30:52PM +0100, Eugenio Perez Martin wrote:
> > You need to pass this to guest. My point is that there is no reason to
> > get it from the kernel driver. QEMU can figure out whether the flag is
> > needed itself.
> >
>
> Ok, I can see now how the HW device does not have all the knowledge to
> offer this flag or not. But I'm not sure how qemu can know either.
>
> If qemu opens /dev/vhost-vdpa-N, how can it know it? It has no way to
> tell if the device is sw or hw as far as I know. Am I missing
> something?
>
> Thanks!
This is what I said earlier. You can safely assume vdpa needs this
flag. Only exception is vduse and we don't care about performance there.
--
MST
next prev parent reply other threads:[~2023-03-02 11:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 19:19 [PATCH] vhost: accept VIRTIO_F_ORDER_PLATFORM as a valid SVQ feature Eugenio Pérez
2023-02-14 6:31 ` Jason Wang
2023-02-14 7:02 ` Eugenio Perez Martin
2023-02-14 7:50 ` Michael S. Tsirkin
2023-02-14 8:36 ` Eugenio Perez Martin
2023-03-01 21:37 ` Michael S. Tsirkin
2023-03-02 11:30 ` Eugenio Perez Martin
2023-03-02 11:43 ` Michael S. Tsirkin [this message]
2023-03-02 14:47 ` Eugenio Perez Martin
2023-03-02 23:31 ` Michael S. Tsirkin
2023-03-03 9:08 ` Eugenio Perez Martin
2023-03-03 9:16 ` Michael S. Tsirkin
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=20230302064234-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alvaro.karsz@solid-run.com \
--cc=eli@mellanox.com \
--cc=eperezma@redhat.com \
--cc=gdawar@xilinx.com \
--cc=jasowang@redhat.com \
--cc=leiyang@redhat.com \
--cc=lingshan.zhu@intel.com \
--cc=longpeng2@huawei.com \
--cc=lulu@redhat.com \
--cc=lvivier@redhat.com \
--cc=parav@mellanox.com \
--cc=qemu-devel@nongnu.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: 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.