qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ENQCMD


From: Stefan Hajnoczi
Subject: ENQCMD
Date: Fri, 30 Oct 2020 07:50:46 +0000

Hi,
The "Scalable Work Submission in Device Virtualization" talk at KVM
Forum 2020 was interesting and I have some beginner questions about
ENQCMD:
https://static.sched.com/hosted_files/kvmforum2020/22/Scalable_Work_Submission_In_Device_Virtualization.pdf

Security
--------
If the ENQCMD instruction is allowed for userspace applications, how can
they be prevented from writing to the MMIO address directly (without the
ENQCMD instruction) and faking the 64-byte enqueue register data format?
For example, they could set the PRIV bit or an arbitrary PASID.

Work Queue Design
-----------------
Have you looked at extending existing hardware interfaces like NVMe or
VIRTIO to support enqueue registers?

Have you benchmarked NVMe or VIRTIO devices using ENQCMD instead of
the traditional submission queuing mechanism?

Is ENQCMD faster than traditional I/O request submission? If not, then I
guess it's only intended for shared queues where the PASID translation
is needed?

A few thoughts come to mind:

 * Traditional submission queues are no longer needed and can be
   replaced by an enqueue register. NVMe sqs and VIRTIO avail rings
   aren't needed anymore, although the sqes and vring descriptors are
   still needed to represent commands and buffers.

   Or the enqueue register can be used simply as a doorbell to start DMA
   reading requests from a traditional submission queue. In this case
   the advantage is that a single shared hardware unit (ADI) can emulate
   multiple queues at the same time.

 * In order to support submitting multiple requests in a single enqueue
   register access there needs to be some kind of chaining mechanism.
   For example, the Device Specific Command field contains a num_reqs
   field telling the device how many requests to DMA.

I don't know much about ENQCMD and am trying to figure out where it fits
in. Please let me know if this matches how this feature is intended to
be used.

Thanks,
Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]