On 6/3/2019 5:14 AM, Kevin Wolf wrote:
Am 28.05.2019 um 08:18 hat Klaus Birkelund geschrieben:
On Mon, May 20, 2019 at 11:40:30AM -0600, Kenneth Heitke wrote:
Signed-off-by: Kenneth Heitke <kenneth.hei...@intel.com>

diff --git a/hw/block/nvme.h b/hw/block/nvme.h
index 56c9d4b4b1..d7277e72b7 100644
--- a/hw/block/nvme.h
+++ b/hw/block/nvme.h
@@ -69,6 +69,7 @@ typedef struct NvmeCtrl {
      uint16_t    max_prp_ents;
      uint16_t    cqe_size;
      uint16_t    sqe_size;
+    uint16_t    oncs;

Looks like this unused member snuck its way into the patch. But I see no
harm in it being there.

Good catch. I'll just remove it again from my branch.

+static inline void nvme_set_timestamp(NvmeCtrl *n, uint64_t ts)
+{
+    trace_nvme_setfeat_timestamp(ts);
+
+    n->host_timestamp = le64_to_cpu(ts);
+    n->timestamp_set_qemu_clock_ms = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
+}
+
+static inline uint64_t nvme_get_timestamp(const NvmeCtrl *n)
+{
+    uint64_t current_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);

Here I wonder why we use QEMU_CLOCK_REALTIME in a device emulation.
Wouldn't QEMU_CLOCK_VIRTUAL make more sense?


QEMU_CLOCK_VIRTUAL probably would make more sense. When I was reading through the differences I wasn't really sure what to pick. iven that this is the time within the device's context, the virtual time seems more correct.

Kevin


Reply via email to