-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
virtio.h: add memory operation for virtio device #541
base: main
Are you sure you want to change the base?
Conversation
3c591de
to
d31e41a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some cosmetics questions plus minor comment for this first round.
lib/include/openamp/virtio.h
Outdated
static inline void *virtio_alloc_buf(struct virtio_device *vdev, | ||
size_t size, size_t align) | ||
{ | ||
return vdev->func->alloc_buf(vdev, size, align); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check argumentts:
- vdev -> return -EINVAL if NULL;
- alloc_buf -> function may be not supported, check if it exists first and return -ENXIO if NULL
lib/include/openamp/virtio.h
Outdated
*/ | ||
static inline void virtio_free_buf(struct virtio_device *vdev, void *buf) | ||
{ | ||
vdev->func->free_buf(vdev, buf); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check argumentts:
- vdev -> return -EINVAL if NULL;
- free_buf -> function may be not supported, check if it exists first and return -ENXIO if NULL
lib/remoteproc/remoteproc_virtio.c
Outdated
return; | ||
|
||
rpvdev->free_buf(rpvdev, buf); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should call the public functions from virtio top layer interface and let it to redirect to vdev specific alloc/free function instead of invoking the dispatch functions directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your suggestion, I'm a little confused, my motivation is that different platforms may have different memory management strategies for remoteproc transport layer, so I introduce function rproc_virtio_set_mm_callback()
to let the platform set their own share memory allocate and free functions.
Do you mean we should add a memory operations to the virtio device and then we can make different virtio devices implement their own share memory management strategies?
lib/include/openamp/virtio.h
Outdated
|
||
/** Free buffer to transport layer heap */ | ||
void (*free_buf)(struct virtio_device *vdev, void *buf); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to me that it is not the good place to add these functions
The memory allocation/free is independent from the virtio layer as addressed directly to the transport layer.
The virtio_dispatch
is used for communication between the virtio layer and the transport layer
What about a new structure similar to virtio_dispatch
? virtio_mem_ops
or a better name...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems better, I will try this, Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, please review again @arnopo
This pull request has been marked as a stale pull request because it has been open (more than) 45 days with no activity. |
d31e41a
to
58d5fac
Compare
Buffer management is different for different transport layer: For MMIO transport layer, the buffer can direclty malloced from the gust os heap beacase the hypervisor can access all the memmory own by guest os. For remoteproc transpor layer, the buffer should be malloced from the share memory region to make sure the remote core can access this buffer too. So add memory ops in virtio device to make different transport/device can implement their own share memory management. Signed-off-by: Bowen Wang <[email protected]>
58d5fac
to
f58cce3
Compare
Hi @CV-Bowen, Your proposal seems reasonable. For your information, in the meantime, there is a working group initiated by ARM around a new Virtio transport called virtio-msg. This group aims to propose a new Virtio transport that should support virtualization and AMP systems. One objective is also to address memory allocation challenges. My current concern with your PR is that Integrating your work now would imply that we probably have two APIs to support or deprecate this one in the short/middle term. We have to discuss with the OpenAMP team to determine the strategy we want. |
@arnopo Thank you for your reply and waiting for your decisions. |
We discussed the PR in the OpenAMP meeting. The decision is to postpone this PR to the next release to give more time to verify that this approach will also fit the other virtio transports. |
when will the next release out? it's always better to merge this patch immediately after the release branch? so the community could try this change as soon as possible. |
That seems reasonable to me , need first reviews from @edmooring and/or @tnmysh |
Buffer management is different for different transport layer:
For MMIO transport layer, the buffer can direclty malloced from
the gust os heap beacase the hypervisor can access all the memmory own
by guest os.
For remoteproc transpor layer, the buffer should be malloced from
the share memory region to make sure the remote core can access this
buffer too.
So add memory ops in virtio device to make different transport/device can
implement their own share memory management.