tmakatos / spdk

Storage Performance Development Kit
https://spdk.io/
Other
0 stars 1 forks source link

Warning about failure to map queue #2

Closed tmakatos closed 3 years ago

tmakatos commented 4 years ago

After the guest boots I see the following

[2020-09-16 05:31:23.240761] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffd8000-0x3ffdc000
[2020-09-16 05:31:23.240981] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffde000-0x3ffdf000
[2020-09-16 05:31:23.241008] muser.c:1228:map_admin_queue: *ERROR*: /var/run/muser/foo/0: failed to map CQ0: -1
[2020-09-16 05:31:23.241027] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffd8000-0x3ffdc000
[2020-09-16 05:31:23.241260] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffde000-0x3ffdf000
[2020-09-16 05:31:23.241275] muser.c:1228:map_admin_queue: *ERROR*: /var/run/muser/foo/0: failed to map CQ0: -1
[2020-09-16 05:31:23.241292] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffd8000-0x3ffdc000
[2020-09-16 05:31:23.241527] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffde000-0x3ffdf000
[2020-09-16 05:31:23.241543] muser.c:1228:map_admin_queue: *ERROR*: /var/run/muser/foo/0: failed to map CQ0: -1
[2020-09-16 05:31:23.241564] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffd8000-0x3ffdc000
[2020-09-16 05:31:23.241776] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffde000-0x3ffdf000
[2020-09-16 05:31:23.241792] muser.c:1228:map_admin_queue: *ERROR*: /var/run/muser/foo/0: failed to map CQ0: -1
[2020-09-16 05:31:23.241812] muser.c: 432:map_one: *ERROR*: failed to map 0x3ffd8000-0x3ffdc000

Full log: nvmf_tgt.zip.

changpe1 commented 4 years ago

In the unmap_dma callback, because the DMA region was removed, so we will set the queue state to VFIO_USER_QPAIR_INACTIVE, and in the map_dma callback, we don't know the queue's physical address belong to this region or not, so just try to map the queue's physical address.

It's an error log but doesn't affect anything for now.

tmakatos commented 4 years ago

Then I suppose it's trivial to check whether the queue's address is within the DMA region being added and avoid attempting to map it if it isn't right?

changpe1 commented 4 years ago

Then I suppose it's trivial to check whether the queue's address is within the DMA region being added and avoid attempting to map it if it isn't right?

Yeah, you can check the address is in the map_dma range or not to avoid attempting to map it.