qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-devel@nongnu.org, agraf@suse.de, armbru@redhat.com,
	michael@ellerman.id.au, qemu-ppc@nongnu.org,
	amit.shah@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 2/2] ppc/spapr_hcall: Implement H_RANDOM hypercall in QEMU
Date: Mon, 7 Sep 2015 17:05:48 +0200	[thread overview]
Message-ID: <55EDA7CC.4000905@redhat.com> (raw)
In-Reply-To: <20150901004753.GJ11475@voom.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3645 bytes --]

On 01/09/15 02:47, David Gibson wrote:
> On Mon, Aug 31, 2015 at 08:46:02PM +0200, Thomas Huth wrote:
>> The PAPR interface provides a hypercall to pass high-quality
>> hardware generated random numbers to guests. So let's provide
>> this call in QEMU, too, so that guests that do not support
>> virtio-rnd yet can get good random numbers, too.
>> Please note that this hypercall should provide "good" random data
>> instead of pseudo-random, so the function uses the RngBackend to
>> retrieve the values instead of using a "simple" library function
>> like rand() or g_random_int(). Since there are multiple RngBackends
>> available, the user must select an appropriate backend via the
>> "h-random" property of the the machine state to enable it, e.g.
>>
>>  qemu-system-ppc64 -M pseries,h-random=rng-random ...
...
>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>> index 652ddf6..ff9d4fd 100644
>> --- a/hw/ppc/spapr_hcall.c
>> +++ b/hw/ppc/spapr_hcall.c
>> @@ -1,4 +1,8 @@
>>  #include "sysemu/sysemu.h"
>> +#include "sysemu/rng.h"
>> +#include "sysemu/rng-random.h"
>> +#include "qom/object_interfaces.h"
>> +#include "qemu/error-report.h"
>>  #include "cpu.h"
>>  #include "helper_regs.h"
>>  #include "hw/ppc/spapr.h"
>> @@ -929,6 +933,77 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu_,
>>      return H_SUCCESS;
>>  }
>>  
>> +typedef struct HRandomData {
>> +    QemuSemaphore sem;
>> +    union {
>> +        uint64_t v64;
>> +        uint8_t v8[8];
>> +    } val;
>> +    int received;
>> +} HRandomData;
>> +
>> +static RndRandom *hrandom_rng;
> 
> Couldn't you avoid the new global by looking this up through the
> sPAPRMachineState?
> 
>> +
>> +static void random_recv(void *dest, const void *src, size_t size)
>> +{
>> +    HRandomData *hrcrdp = dest;
>> +
>> +    if (src && size > 0) {
>> +        memcpy(&hrcrdp->val.v8[hrcrdp->received], src, size);
> 
> I'd be happier with an assert() ensuring that size doesn't exceed the
> buffer space we have left.
> 
>> +        hrcrdp->received += size;
>> +    }
>> +    qemu_sem_post(&hrcrdp->sem);
> 
> Could you avoid a few wakeups by only posting the semaphore once the
> buffer is filled?

I tried that now, but calling rng_backend_request_entropy() from within
the callback function does not work (since entropy_available() in
rng-random.c clears the callback function variable after having called
the callback).

And since you normally seem get 8 bytes in the first shot already anyway
when using a good random number generator source, I think it's best to
simply keep the logic as I've currently got it - at least that's easiest
to understand when reading the source code.

>> +}
>> +
>> +static target_ulong h_random(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>> +                             target_ulong opcode, target_ulong *args)
>> +{
>> +    HRandomData hrcrd;
>> +
>> +    if (!hrandom_rng) {
>> +        return H_HARDWARE;
>> +    }
>> +
>> +    qemu_sem_init(&hrcrd.sem, 0);
>> +    hrcrd.val.v64 = 0;
>> +    hrcrd.received = 0;
>> +
>> +    qemu_mutex_unlock_iothread();
>> +    while (hrcrd.received < 8) {
>> +        rng_backend_request_entropy((RngBackend *)hrandom_rng,
>> +                                    8 - hrcrd.received, random_recv, &hrcrd);
>> +        qemu_sem_wait(&hrcrd.sem);
>> +    }
>> +    qemu_mutex_lock_iothread();
>> +
>> +    qemu_sem_destroy(&hrcrd.sem);
>> +    args[0] = hrcrd.val.v64;
>> +
>> +    return H_SUCCESS;
>> +}

I'll post a new version with the other changes soon.

 Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2015-09-07 15:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-31 18:46 [Qemu-devel] [PATCH v2 0/2] ppc/spapr_hcall: Implement H_RANDOM hypercall Thomas Huth
2015-08-31 18:46 ` [Qemu-devel] [PATCH v2 1/2] spapr: Add support for hwrng when available Thomas Huth
2015-09-01  0:38   ` David Gibson
2015-09-01 10:53     ` Thomas Huth
2015-09-08  5:03       ` [Qemu-devel] [Qemu-ppc] " Sam Bobroff
2015-09-08  5:15         ` David Gibson
2015-09-09 21:10           ` Thomas Huth
2015-09-10  7:33             ` Thomas Huth
2015-09-10 10:40               ` David Gibson
2015-09-10 12:03                 ` Thomas Huth
2015-09-10 12:13                   ` Alexander Graf
2015-09-11  0:46                     ` David Gibson
2015-09-11  9:43                       ` Alexander Graf
2015-09-14  2:27                         ` David Gibson
2015-09-14  7:36                           ` Alexander Graf
2015-09-11  0:45                   ` David Gibson
2015-09-11  7:30                     ` Thomas Huth
2015-09-14  2:25                       ` David Gibson
2015-09-08  5:38         ` Thomas Huth
2015-09-09  0:54           ` Sam Bobroff
2015-09-10 12:06             ` Greg Kurz
2015-09-09 14:09   ` [Qemu-devel] " Greg Kurz
2015-08-31 18:46 ` [Qemu-devel] [PATCH v2 2/2] ppc/spapr_hcall: Implement H_RANDOM hypercall in QEMU Thomas Huth
2015-09-01  0:47   ` David Gibson
2015-09-01 11:03     ` Thomas Huth
2015-09-07 15:05     ` Thomas Huth [this message]
2015-09-08  1:14       ` David Gibson
2015-09-02  5:34   ` Amit Shah
2015-09-02  7:48     ` David Gibson
2015-09-02  8:58       ` Thomas Huth
2015-09-02 10:06         ` Amit Shah
2015-09-02 10:02       ` Amit Shah
2015-09-03  1:21       ` Michael Ellerman
2015-09-03  2:17         ` David Gibson

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=55EDA7CC.4000905@redhat.com \
    --to=thuth@redhat.com \
    --cc=agraf@suse.de \
    --cc=amit.shah@redhat.com \
    --cc=armbru@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=michael@ellerman.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).