Skip to content
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

Refactor VRING macros for AMP VIRTIO #505

Merged
merged 1 commit into from
Oct 10, 2023
Merged

Conversation

danmilea
Copy link
Collaborator

@danmilea danmilea commented Oct 2, 2023

Renamed AMP VIRTIO macros to avoid conflicts.

Copy link
Collaborator

@arnopo arnopo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank @danmilea for the reactivity. few comments/questions

@@ -152,7 +152,7 @@ struct virtio_device_id {
sizeof(struct vring_used_elem) * n + sizeof(uint16_t))

#define VRING_DECLARE(name, n, align) \
static char __vrbuf_##name[VIRTIO_RING_SIZE(n, align)] __aligned(VRING_ALIGNMENT); \
static char __vrbuf_##name[VIRTIO_RING_SIZE(n, align)] __aligned(VIRTIO_AMP_VRING_ALIGNMENT); \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If i well understood here you expect to reserve vrings memory with a VIRTIO_AMP_VRING_ALIGNMENT Alignement. to guaranty that a 4K page is reserved for one vring.

What about using a parammeter instead of hardcoding it?
And how do you ensure that the host is aligned with the _vrbuf##name address?
As there is not usage yet of this macro, I would be in favor of removing it and reintroduce it when used.
else we should maintain it evenif not usable in a generic way.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the define in the newer version of the PR.

@@ -286,7 +286,7 @@ struct virtqueue *virtio_mmio_setup_virtqueue(struct virtio_device *vdev,

vring_info->io = vmdev->shm_io;
vring_info->info.num_descs = virtio_mmio_get_max_elem(vdev, idx);
vring_info->info.align = VRING_ALIGNMENT;
vring_info->info.align = VIRTIO_AMP_VRING_ALIGNMENT;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The align is used by vq_ring_init. That's means that you align the vring_used struct on a new 4k page right?
That would mean that the vring is on two 4k page...

Copy link
Collaborator Author

@danmilea danmilea Oct 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what the math says, but it's not different from using the virtqeue/vring creation API with an explicit alignment of 4096. This is also the value for vring alignment defined in several resource tables (rsc_table.c) for zynqmp_r5, microblaze_generic, zynqmp_r5 or the linux generic machine.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what the math says, but it's not different from using the virtqeue/vring creation API with an explicit alignment of 4096. This is also the value for vring alignment defined in several resource tables (rsc_table.c) for zynqmp_r5, microblaze_generic, zynqmp_r5 or the linux generic machine.

As you mention it is on some resource table but unfortunatly not all. For instance the generic implementation of the resource table on zephyr: https://elixir.bootlin.com/zephyr/v3.5.0-rc1/source/lib/open-amp/resource_table.h#L29.

So that will be need to be adapted to be generic, and could impact virtio_mmio_setup_virtqueue() parameters...

Copy link
Collaborator

@arnopo arnopo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a minor comment on the constant naming else LGTM for this step

@@ -286,7 +286,7 @@ struct virtqueue *virtio_mmio_setup_virtqueue(struct virtio_device *vdev,

vring_info->io = vmdev->shm_io;
vring_info->info.num_descs = virtio_mmio_get_max_elem(vdev, idx);
vring_info->info.align = VRING_ALIGNMENT;
vring_info->info.align = VIRTIO_AMP_VRING_ALIGNMENT;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what the math says, but it's not different from using the virtqeue/vring creation API with an explicit alignment of 4096. This is also the value for vring alignment defined in several resource tables (rsc_table.c) for zynqmp_r5, microblaze_generic, zynqmp_r5 or the linux generic machine.

As you mention it is on some resource table but unfortunatly not all. For instance the generic implementation of the resource table on zephyr: https://elixir.bootlin.com/zephyr/v3.5.0-rc1/source/lib/open-amp/resource_table.h#L29.

So that will be need to be adapted to be generic, and could impact virtio_mmio_setup_virtqueue() parameters...

.used = (void *)((unsigned long)__vrbuf_##name + ((n * sizeof(struct vring_desc) + \
(n + 1) * sizeof(uint16_t) + align - 1) & ~(align - 1))), \
}
#define VIRTIO_AMP_VRING_ALIGNMENT 4096
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VIRTIO_MMIO_VRING_ALIGNMENT seems to be more appropriate since it is currently only used for the virtio mmio.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Renamed AMP VIRTIO macros to avoid conflicts.

Signed-off-by: Dan Milea <[email protected]>
@arnopo arnopo added this to the Release V2023.10 milestone Oct 3, 2023
Copy link
Contributor

@edmooring edmooring left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to go.

@arnopo arnopo merged commit bdf5f91 into OpenAMP:main Oct 10, 2023
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants