From: Vishnu Dasa <[email protected]>
Add support for ARM64 architecture so that the driver can now be built
and VMCI device can be used.
Update Kconfig file to allow the driver to be built on ARM64 as well.
Fail vmci_guest_probe_device() on ARM64 if the device does not support
MMIO register access. Lastly, add virtualization specific barriers
which map to actual memory barrier instructions on ARM64, because it
is required in case of ARM64 for queuepair (de)queuing.
Reviewed-by: Bryan Tan <[email protected]>
Reviewed-by: Cyprien Laplace <[email protected]>
Signed-off-by: Vishnu Dasa <[email protected]>
---
drivers/misc/vmw_vmci/Kconfig | 2 +-
drivers/misc/vmw_vmci/vmci_guest.c | 4 ++++
drivers/misc/vmw_vmci/vmci_queue_pair.c | 12 ++++++++++++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig
index 605794aadf11..b6d4d7fd686a 100644
--- a/drivers/misc/vmw_vmci/Kconfig
+++ b/drivers/misc/vmw_vmci/Kconfig
@@ -5,7 +5,7 @@
config VMWARE_VMCI
tristate "VMware VMCI Driver"
- depends on X86 && PCI
+ depends on (X86 || ARM64) && !CPU_BIG_ENDIAN && PCI
help
This is VMware's Virtual Machine Communication Interface. It enables
high-speed communication between host and guest in a virtual
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c b/drivers/misc/vmw_vmci/vmci_guest.c
index 57a6157209a1..aa7b05de97dd 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -614,6 +614,10 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
}
if (!mmio_base) {
+ if (IS_ENABLED(CONFIG_ARM64)) {
+ dev_err(&pdev->dev, "MMIO base is invalid\n");
+ return -ENXIO;
+ }
error = pcim_iomap_regions(pdev, BIT(0), KBUILD_MODNAME);
if (error) {
dev_err(&pdev->dev, "Failed to reserve/map IO regions\n");
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index 94ebf7f3fd58..8f2de1893245 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -2577,6 +2577,12 @@ static ssize_t qp_enqueue_locked(struct vmci_queue *produce_q,
if (result < VMCI_SUCCESS)
return result;
+ /*
+ * This virt_wmb() ensures that data written to the queue
+ * is observable before the new producer_tail is.
+ */
+ virt_wmb();
+
vmci_q_header_add_producer_tail(produce_q->q_header, written,
produce_q_size);
return written;
@@ -2620,6 +2626,12 @@ static ssize_t qp_dequeue_locked(struct vmci_queue *produce_q,
if (buf_ready < VMCI_SUCCESS)
return (ssize_t) buf_ready;
+ /*
+ * This virt_rmb() ensures that data from the queue will be read
+ * after we have determined how much is ready to be consumed.
+ */
+ virt_rmb();
+
read = (size_t) (buf_ready > buf_size ? buf_size : buf_ready);
head = vmci_q_header_consumer_head(produce_q->q_header);
if (likely(head + read < consume_q_size)) {
--
2.35.1
[email protected] writes:
> From: Vishnu Dasa <[email protected]>
>
> Add support for ARM64 architecture so that the driver can now be built
> and VMCI device can be used.
>
> Update Kconfig file to allow the driver to be built on ARM64 as well.
> Fail vmci_guest_probe_device() on ARM64 if the device does not support
> MMIO register access. Lastly, add virtualization specific barriers
> which map to actual memory barrier instructions on ARM64, because it
> is required in case of ARM64 for queuepair (de)queuing.
>
FWIW, it seems you're doing three things at once, better split this into
a 3-patch series.
> Reviewed-by: Bryan Tan <[email protected]>
> Reviewed-by: Cyprien Laplace <[email protected]>
> Signed-off-by: Vishnu Dasa <[email protected]>
> ---
> drivers/misc/vmw_vmci/Kconfig | 2 +-
> drivers/misc/vmw_vmci/vmci_guest.c | 4 ++++
> drivers/misc/vmw_vmci/vmci_queue_pair.c | 12 ++++++++++++
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig
> index 605794aadf11..b6d4d7fd686a 100644
> --- a/drivers/misc/vmw_vmci/Kconfig
> +++ b/drivers/misc/vmw_vmci/Kconfig
> @@ -5,7 +5,7 @@
>
> config VMWARE_VMCI
> tristate "VMware VMCI Driver"
> - depends on X86 && PCI
> + depends on (X86 || ARM64) && !CPU_BIG_ENDIAN && PCI
> help
> This is VMware's Virtual Machine Communication Interface. It enables
> high-speed communication between host and guest in a virtual
> diff --git a/drivers/misc/vmw_vmci/vmci_guest.c b/drivers/misc/vmw_vmci/vmci_guest.c
> index 57a6157209a1..aa7b05de97dd 100644
> --- a/drivers/misc/vmw_vmci/vmci_guest.c
> +++ b/drivers/misc/vmw_vmci/vmci_guest.c
> @@ -614,6 +614,10 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
> }
>
> if (!mmio_base) {
> + if (IS_ENABLED(CONFIG_ARM64)) {
> + dev_err(&pdev->dev, "MMIO base is invalid\n");
> + return -ENXIO;
> + }
> error = pcim_iomap_regions(pdev, BIT(0), KBUILD_MODNAME);
> if (error) {
> dev_err(&pdev->dev, "Failed to reserve/map IO regions\n");
> diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c b/drivers/misc/vmw_vmci/vmci_queue_pair.c
> index 94ebf7f3fd58..8f2de1893245 100644
> --- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
> +++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
> @@ -2577,6 +2577,12 @@ static ssize_t qp_enqueue_locked(struct vmci_queue *produce_q,
> if (result < VMCI_SUCCESS)
> return result;
>
> + /*
> + * This virt_wmb() ensures that data written to the queue
> + * is observable before the new producer_tail is.
> + */
> + virt_wmb();
> +
> vmci_q_header_add_producer_tail(produce_q->q_header, written,
> produce_q_size);
> return written;
> @@ -2620,6 +2626,12 @@ static ssize_t qp_dequeue_locked(struct vmci_queue *produce_q,
> if (buf_ready < VMCI_SUCCESS)
> return (ssize_t) buf_ready;
>
> + /*
> + * This virt_rmb() ensures that data from the queue will be read
> + * after we have determined how much is ready to be consumed.
> + */
> + virt_rmb();
> +
> read = (size_t) (buf_ready > buf_size ? buf_size : buf_ready);
> head = vmci_q_header_consumer_head(produce_q->q_header);
> if (likely(head + read < consume_q_size)) {
--
Vitaly
> FWIW, it seems you're doing three things at once, better split this into
> a 3-patch series.
Thanks for the feedback. I was debating between the two ways of doing
it and ultimately did it one way. It is a bit late now to change it as it has
made its way to linux-next already.
Thanks,
Vishnu
On Wed, May 11, 2022 at 9:54 PM Vishnu Dasa <[email protected]> wrote:
>
>
> > FWIW, it seems you're doing three things at once, better split this into
> > a 3-patch series.
>
> Thanks for the feedback. I was debating between the two ways of doing
> it and ultimately did it one way. It is a bit late now to change it as it has
> made its way to linux-next already.
It's really ok either way here. While there are clearly multiple changes in the
source file, they are all trivial, and the Kconfig change doesn't make sense
without the other changes, so having a combined patch seems totally
reasonable as well.
Arnd