From: "Michael S. Tsirkin" <mst@redhat.com>
To: Linhaifeng <haifeng.lin@huawei.com>
Cc: qemu-devel@nongnu.org, n.nikolaev@virtualopensystems.com,
jerry.lilijun@huawei.com
Subject: Re: [Qemu-devel] vhost-user: VHOST_SET_MEM_TABLE, VHOST_SET_VRING_CALL need a reply?
Date: Thu, 18 Sep 2014 08:19:45 +0300 [thread overview]
Message-ID: <20140918051945.GB23433@redhat.com> (raw)
In-Reply-To: <541A45C4.8060305@huawei.com>
On Thu, Sep 18, 2014 at 10:39:00AM +0800, Linhaifeng wrote:
>
>
> On 2014/9/17 17:56, Michael S. Tsirkin wrote:
> > On Wed, Sep 17, 2014 at 05:39:04PM +0800, Linhaifeng wrote:
> >> I think maybe is not need for the backend to wait for response.
> >>
> >> There is another way.vhost-user send "VHOST_GET_MEM_TABLE" to qemu then qemu send VHOST_SET_MEM_TABLE to update the regions of vhost-user.same as other command.
> >> If qemu could response the request of the vhost-user.the vhost-user could update date at anytime.
> >
> > The updates are initiated by QEMU, as a result of IOMMU,
> > memory hotplug or some other configuration change.
>
> yes.when memory unplug/plug should tell vhost-user.
Right. So VHOST_SET_MEM_TABLE needs a response then, at least
for cases when it's freeing memory.
When memory is added, we can avoid waiting for the response
if vhost-user can detect a fault and flush the incoming
command pipe looking for VHOST_SET_MEM_TABLE.
> >
> >> I think it's very useful for Commercialization.
> >>
> >> On 2014/9/17 16:38, Michael S. Tsirkin wrote:
> >>> Reply-To:
> >>>
> >>> Thinking about the vhost-user protocol, VHOST_SET_MEM_TABLE
> >>> is used to update the memory mappings.
> >>>
> >>> So shouldn't we want for response?
> >>> Otherwise e.g. guest can start using the memory
> >>> that vhost-user can't access.
> >>>
> >>> Similarly, with an IOMMU vhost-user might access memory it shouldn't.
> >>>
> >>> VHOST_SET_VRING_CALL is used for MSI-X masking.
> >>> Again, after vector is masted by switching the call fd,
> >>> backend shouldn't assert the old one.
> >>>
> >>> Thoughts?
> >>>
> >>>
> >
> > .
> >
prev parent reply other threads:[~2014-09-18 5:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-17 8:38 [Qemu-devel] vhost-user: VHOST_SET_MEM_TABLE, VHOST_SET_VRING_CALL need a reply? Michael S. Tsirkin
2014-09-17 9:39 ` Linhaifeng
2014-09-17 9:56 ` Michael S. Tsirkin
2014-09-18 0:45 ` Linhaifeng
2014-09-18 5:16 ` Michael S. Tsirkin
2014-09-18 12:39 ` Linhaifeng
2014-09-18 12:54 ` Michael S. Tsirkin
2014-09-18 2:39 ` Linhaifeng
2014-09-18 5:19 ` Michael S. Tsirkin [this message]
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=20140918051945.GB23433@redhat.com \
--to=mst@redhat.com \
--cc=haifeng.lin@huawei.com \
--cc=jerry.lilijun@huawei.com \
--cc=n.nikolaev@virtualopensystems.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.