On 28-Aug-18 9:42 AM, Tiwei Bie wrote:
On Tue, Aug 28, 2018 at 09:12:38AM +0100, Burakov, Anatoly wrote:
On 28-Aug-18 8:53 AM, Tiwei Bie wrote:
[...]
- for (i = 0; i < num; ++i) {
- mr = &msg->payload.memory.regions[i];
- mr->guest_phys_addr = huges[i].addr; /* use vaddr! */
- mr->userspace_addr = huges[i].addr;
- mr->memory_size = huges[i].size;
- mr->mmap_offset = 0;
- fds[i] = open(huges[i].path, O_RDWR);
+ start_addr = (uint64_t)(uintptr_t)ms->addr;
+ end_addr = start_addr + ms->len;
+
+ /*
+ * XXX workaround!
+ *
+ * For --single-file-segments case, offset should be:
+ * offset = rte_fbarray_find_idx(&msl->memseg_arr, ms) * msl->page_sz;
+ *
+ * But it's not true for non-single-file-segments case.
+ *
+ * This is a temporary workaround which assumes the file will
+ * also be mapped from the beginning in --single-file-segments
+ * case. It should be replaced when we have a memory API to
+ * get the offset.
Yes, this is an unfortunate consequence of having split personalities in
memory subsystem. A good solution would be to just deprecate
non-single-file segments mode and always use it, but we cannot do that
because we support kernel versions that do not support fallocate() on
hugetlbfs (and it still leaves legacy mem mode, which effectively
behaves like non-single-file segments as far as virtio is concerned).
How about we add this API in v2 for seg fd patchset?
Sure, thanks!
Besides, I saw another minor issue. When --legacy-mem
and --single-file-segments are both specified, the EAL
init doesn't fail, but fd can't be got successfully.
I'll have to look into this, because as far as i recall, i've submitted
a patch specifically prohibiting legacy mem combined with single file
segments. I'll double check though. Thanks for testing!
--
Thanks,
Anatoly
