From: "Michael S. Tsirkin" <mst@redhat.com>
To: Raphael Norwitz <raphael.s.norwitz@gmail.com>
Cc: zhang.zhanghailiang@huawei.com, jasowang@redhat.com,
QEMU <qemu-devel@nongnu.org>,
xiexiangyou@huawei.com,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Jiajun Chen" <chenjiajun8@huawei.com>,
"Igor Mammedov" <imammedo@redhat.com>
Subject: Re: [PATCH] vhost-user: add separate memslot counter for vhost-user
Date: Wed, 14 Oct 2020 03:08:27 -0400 [thread overview]
Message-ID: <20201014030340-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAFubqFtqXorzk6g9d3A3TFcPnE9eSJKsjfSCK5zwTNX6xtJ3kw@mail.gmail.com>
On Tue, Oct 13, 2020 at 08:58:59PM -0400, Raphael Norwitz wrote:
> On Tue, Oct 6, 2020 at 5:48 AM Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > On Mon, 28 Sep 2020 21:17:31 +0800
> > Jiajun Chen <chenjiajun8@huawei.com> wrote:
> >
> > > Used_memslots is equal to dev->mem->nregions now, it is true for
> > > vhost kernel, but not for vhost user, which uses the memory regions
> > > that have file descriptor. In fact, not all of the memory regions
> > > have file descriptor.
> > > It is usefully in some scenarios, e.g. used_memslots is 8, and only
> > > 5 memory slots can be used by vhost user, it is failed to hot plug
> > > a new memory RAM because vhost_has_free_slot just returned false,
> > > but we can hot plug it safely in fact.
> >
> > I had an impression that all guest RAM has to be shared with vhost,
> > so combination of anon and fd based RAM couldn't work.
> > Am I wrong?
>
> I'm not sure about the kernel backend, but I've tested adding anon
> memory to a VM with a vhost-user-scsi device and it works (eventually
> the VM crashed, but I could see the guest recognized the anon RAM).
> The vhost-user code is designed to work with both. I'm not sure I see
> a use case, but if there is one, this would be a valid issue. Maybe
> Jiajun or Jianjay can elaborate.
Hmm does not vhost-user skip all regions that do not have an fd?
mr = vhost_user_get_mr_data(reg->userspace_addr, &offset, &fd);
if (fd > 0) {
if (track_ramblocks) {
assert(*fd_num < VHOST_MEMORY_BASELINE_NREGIONS);
trace_vhost_user_set_mem_table_withfd(*fd_num, mr->name,
reg->memory_size,
reg->guest_phys_addr,
reg->userspace_addr,
offset);
u->region_rb_offset[i] = offset;
u->region_rb[i] = mr->ram_block;
} else if (*fd_num == VHOST_MEMORY_BASELINE_NREGIONS) {
error_report("Failed preparing vhost-user memory table msg");
return -1;
}
vhost_user_fill_msg_region(®ion_buffer, reg, offset);
msg->payload.memory.regions[*fd_num] = region_buffer;
fds[(*fd_num)++] = fd;
} else if (track_ramblocks) {
u->region_rb_offset[i] = 0;
u->region_rb[i] = NULL;
}
In your test, is it possible that you were lucky and guest did not send
any data from anon memory to the device?
> >
> > >
> > > --
> > > ChangeList:
> > > v3:
> > > -make used_memslots a member of struct vhost_dev instead of a global static value
> > it's global resource, so why?
>
> I suggested it because I thought it made the code a little cleaner.
> I'm not opposed to changing it back, or having it stored at the
> vhost_user level.
next prev parent reply other threads:[~2020-10-14 7:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 13:17 [PATCH] vhost-user: add separate memslot counter for vhost-user Jiajun Chen
2020-10-02 2:05 ` Raphael Norwitz
2020-10-12 11:12 ` chenjiajun
2020-10-14 1:22 ` Raphael Norwitz
2020-10-06 9:48 ` Igor Mammedov
2020-10-14 0:58 ` Raphael Norwitz
2020-10-14 7:08 ` Michael S. Tsirkin [this message]
2020-10-14 16:11 ` Raphael Norwitz
2020-10-14 16:26 ` Michael S. Tsirkin
2020-10-14 17:21 ` Raphael Norwitz
2020-10-14 17:54 ` Michael S. Tsirkin
2020-10-21 14:34 ` Igor Mammedov
2020-10-30 8:39 ` Michael S. Tsirkin
-- strict thread matches above, loose matches on Subject: below --
2020-09-08 6:11 Jiajun Chen
2020-09-08 8:37 ` Michael S. Tsirkin
2020-09-15 1:27 ` Raphael Norwitz
2020-08-11 1:43 Jiajun Chen
2020-08-27 12:11 ` Michael S. Tsirkin
2020-09-02 5:02 ` Raphael Norwitz
2020-08-07 9:47 Jiajun Chen
2020-08-07 9:55 ` no-reply
2020-08-07 8:19 Jiajun Chen
2020-08-07 8:25 ` no-reply
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=20201014030340-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=chenjiajun8@huawei.com \
--cc=imammedo@redhat.com \
--cc=jasowang@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raphael.s.norwitz@gmail.com \
--cc=xiexiangyou@huawei.com \
--cc=zhang.zhanghailiang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).