qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/6] target-ppc: Implement darn instruction


From: Nikunj A Dadhania
Subject: Re: [Qemu-devel] [PATCH 2/6] target-ppc: Implement darn instruction
Date: Tue, 09 Aug 2016 10:24:11 +0530
User-agent: Notmuch/0.21 (https://notmuchmail.org) Emacs/25.0.94.1 (x86_64-redhat-linux-gnu)

David Gibson <address@hidden> writes:

> [ Unknown signature status ]
> On Mon, Aug 08, 2016 at 07:33:37AM +1000, Benjamin Herrenschmidt wrote:
>> On Sun, 2016-08-07 at 23:06 +0530, Nikunj A Dadhania wrote:
>> > +target_ulong helper_darn(uint32_t l)
>> > +{
>> > +    target_ulong r = UINT64_MAX;
>> > +
>> > +    if (l <= 2) {
>> > +        do {
>> > +            r = random() * random();
>> > +            r &= l ? UINT64_MAX : UINT32_MAX;
>> > +        } while (r == UINT64_MAX);
>> > +    }
>> > +
>> > +    return r;
>> > +}
>> >  #endif
>> 
>> Isn't this a bit week ? Look at the implementation of H_RANDOM...
>
> Indeed, you should be using the rng backend that H_RANDOM, virtio-rng
> and the Intel random number instruction all use.

I was looking at implementing this, AFAIU, I have to get a new RNG
object in the initialization routine. We would need an instance of this
per machine. So for pseries I can add in ppc_spapr_init(). I am not sure
in case of linux-user where should this be initialized.

One other place was init_proc_POWER9(), but that will be per cpu and
member of CPUPPCState structure. Advantage is it will work for system
emulation and linux-user both and we would not need a lock.

>
> But, worse than that: even if random() was a good RNG, I'm pretty sure
> than although random() * random() will give you a random number with
> twice as many bits as random() alone, it won't be uniformly
> distributed.  That's probably not what you want.

Right, I had seen that issue.

Regards,
Nikunj




reply via email to

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