All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amit Shah <amit.shah@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andreas Faerber <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 4/4] virtio-rng: hardware random number generator device
Date: Fri, 6 Jul 2012 17:36:03 +0530	[thread overview]
Message-ID: <20120706120603.GA6446@amit.redhat.com> (raw)
In-Reply-To: <4FE9B2A0.2030002@us.ibm.com>

On (Tue) 26 Jun 2012 [08:01:20], Anthony Liguori wrote:
> On 06/26/2012 05:48 AM, Amit Shah wrote:
> >On (Mon) 25 Jun 2012 [17:59:28], Anthony Liguori wrote:
> >>On 06/25/2012 05:46 PM, Anthony Liguori wrote:
> >>>From: Amit Shah<amit.shah@redhat.com>
> >
> >>>diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> >
> >>>+static void virtio_rng_class_init(ObjectClass *klass, void *data)
> >>>+{
> >>>+    DeviceClass *dc = DEVICE_CLASS(klass);
> >>>+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> >>>+
> >>>+    k->init = virtio_rng_init_pci;
> >>>+    k->exit = virtio_rng_exit_pci;
> >>>+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> >>>+    k->device_id = PCI_DEVICE_ID_VIRTIO_RNG;
> >>>+    k->revision = VIRTIO_PCI_ABI_VERSION;
> >>>+    k->class_id = PCI_CLASS_OTHERS;
> >>
> >>WHQL tends to get very particular about PCI classes.  Do we
> >>understand the implications of making this CLASS_OTHERS and WHQL?
> >
> >I've not asked around; will update with info when I get it.
> 
> Thanks.

... and I heard back: PCI_CLASS_OTHERS is fine; no problem.

> >>>+/* Send data from a char device over to the guest */
> >>>+static void chr_read(void *opaque, const void *buf, size_t size)
> >>>+{
> >>>+    VirtIORNG *vrng = opaque;
> >>>+    size_t len;
> >>>+    int offset;
> >>>+
> >>>+    if (!is_guest_ready(vrng)) {
> >>>+        return;
> >>>+    }
> >>>+
> >>>+    offset = 0;
> >>>+    while (offset<   size) {
> >>>+        if (!pop_an_elem(vrng)) {
> >>>+            break;
> >>>+        }
> >>>+        len = iov_from_buf(vrng->elem.in_sg, vrng->elem.in_num,
> >>>+                           buf + offset, 0, size - offset);
> >>>+        offset += len;
> >>>+
> >>>+        virtqueue_push(vrng->vq,&vrng->elem, len);
> >>>+        vrng->popped = false;
> >>>+    }
> >>>+    virtio_notify(&vrng->vdev, vrng->vq);
> >>>+
> >>>+    /*
> >>>+     * Lastly, if we had multiple elems queued by the guest, and we
> >>>+     * didn't have enough data to fill them all, indicate we want more
> >>>+     * data.
> >>>+     */
> >>>+    len = pop_an_elem(vrng);
> >>>+    if (len) {
> >>>+        rng_backend_request_entropy(vrng->rng, size, chr_read, vrng);
> >>>+    }
> >>
> >>Because of this above while() loop, you won't see entropy requests
> >>for every request that comes from the guest depending on how data
> >>gets buffered in the socket.
> >
> >So the issue is we currently can't get the iov_size without popping
> >the elem from the vq.
> 
> I think we could split out some of the logic in virtqueue_pop to
> implement a virtqueue_peek().

Just sent out a series that adds virtqueue_get_avail_bytes() which
does this.  A rebased series on top of that eliminates the need for
popping and save/load of the elem.

		Amit

  parent reply	other threads:[~2012-07-06 12:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1340664362-25603-1-git-send-email-aliguori@us.ibm.com>
2012-07-01 22:06 ` [Qemu-devel] [RFC PATCH 0/4] virtio-rng and RngBackend infrastructure (v2) Paul Brook
2012-07-04 11:46   ` Amit Shah
     [not found] ` <1340664362-25603-5-git-send-email-aliguori@us.ibm.com>
     [not found]   ` <4FE8ED50.3090803@us.ibm.com>
     [not found]     ` <20120626104851.GF11372@amit.redhat.com>
     [not found]       ` <4FE9B2A0.2030002@us.ibm.com>
2012-07-06 12:06         ` Amit Shah [this message]
2012-07-11  9:32           ` [Qemu-devel] [PATCH 4/4] virtio-rng: hardware random number generator device Dor Laor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120706120603.GA6446@amit.redhat.com \
    --to=amit.shah@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.