[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 30 Oct 2020 07:50:46 +0000
The "Scalable Work Submission in Device Virtualization" talk at KVM
Forum 2020 was interesting and I have some beginner questions about
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
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
Description: PGP signature
Stefan Hajnoczi <=