I want to add support for the RNG on Intel's IXP4xx NPU and
looking at the existing hw-random.c code, it is written with
the assumption that the RNG is on the PCI bus. I can put a
big #ifdef ARCH_IXP4XX in there but instead I would rather
rewrite the damn thing to use the device model and have a rng
device class with individual drivers for each RNG model, including
IXP4xx. I'll keep the miscdev interface around but will add a
new interface under /sys/class/rng that the userspace tools
can transition to. Is this OK with folks?
One question I have is about the following comment:
* This data only exists for exporting the supported
* PCI ids via MODULE_DEVICE_TABLE. We do not actually
* register a pci_driver, because someone else might one day
* want to register another driver on the same PCI id.
Why? Is there something else on those IDs that another driver might
care about?
Tnx,
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
When law and duty are one, united by religion, you never become fully
conscious, fully aware of yourself. You are always a little less than
an individual. - Frank Herbert
Deepak Saxena wrote:
> I want to add support for the RNG on Intel's IXP4xx NPU and
> looking at the existing hw-random.c code, it is written with
> the assumption that the RNG is on the PCI bus. I can put a
> big #ifdef ARCH_IXP4XX in there but instead I would rather
> rewrite the damn thing to use the device model and have a rng
> device class with individual drivers for each RNG model, including
> IXP4xx. I'll keep the miscdev interface around but will add a
> new interface under /sys/class/rng that the userspace tools
> can transition to. Is this OK with folks?
How does the hardware export RNG functionality? CPU insn? Magic memory
address? Can it be done 100% in userspace?
> One question I have is about the following comment:
>
> * This data only exists for exporting the supported
> * PCI ids via MODULE_DEVICE_TABLE. We do not actually
> * register a pci_driver, because someone else might one day
> * want to register another driver on the same PCI id.
>
> Why? Is there something else on those IDs that another driver might
> care about?
They are bridge ids, not device ids.
Jeff
On Oct 15 2005, at 06:40, Jeff Garzik was caught saying:
> Deepak Saxena wrote:
> >rewrite the damn thing to use the device model and have a rng
> >device class with individual drivers for each RNG model, including
> >IXP4xx. I'll keep the miscdev interface around but will add a
> >new interface under /sys/class/rng that the userspace tools
> >can transition to. Is this OK with folks?
>
> How does the hardware export RNG functionality? CPU insn? Magic memory
> address? Can it be done 100% in userspace?
It's a magic regsiter we just read/write and could be done in userspace.
I also took a look at MPC85xx and it has the same sort of interface but
also has an error interrupt capability. On second thought a class
interface is overkill b/c there will only be one RNG per system, so
I can just do something like watchdogs where we have a bunch of simple
drivers exposing the same interface. We could do it in user space but
then we have separate RNG implementations for x86 and !x86 and I'd
rather not see that. Can we move the x86 code out to userspace and
just let the daemon eat the numbers directly from HW? We can mmap()
PCI devices, but I don't know enough about x86 to say whether msr
instructions can execute out of userspace (or if we want them to...).
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
When law and duty are one, united by religion, you never become fully
conscious, fully aware of yourself. You are always a little less than
an individual. - Frank Herbert
Followup to: <[email protected]>
By author: Deepak Saxena <[email protected]>
In newsgroup: linux.dev.kernel
>
> It's a magic regsiter we just read/write and could be done in userspace.
> I also took a look at MPC85xx and it has the same sort of interface but
> also has an error interrupt capability. On second thought a class
> interface is overkill b/c there will only be one RNG per system, so
> I can just do something like watchdogs where we have a bunch of simple
> drivers exposing the same interface. We could do it in user space but
> then we have separate RNG implementations for x86 and !x86 and I'd
> rather not see that. Can we move the x86 code out to userspace and
> just let the daemon eat the numbers directly from HW? We can mmap()
> PCI devices, but I don't know enough about x86 to say whether msr
> instructions can execute out of userspace (or if we want them to...).
>
MSR instructions cannot execute out of userspace, but the MSR driver
might be possible to use. It's usually quite slow, however.
-hpa
H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Deepak Saxena <[email protected]>
> In newsgroup: linux.dev.kernel
>
>>It's a magic regsiter we just read/write and could be done in userspace.
>>I also took a look at MPC85xx and it has the same sort of interface but
>>also has an error interrupt capability. On second thought a class
>>interface is overkill b/c there will only be one RNG per system, so
>>I can just do something like watchdogs where we have a bunch of simple
>>drivers exposing the same interface. We could do it in user space but
>>then we have separate RNG implementations for x86 and !x86 and I'd
>>rather not see that. Can we move the x86 code out to userspace and
>>just let the daemon eat the numbers directly from HW? We can mmap()
>>PCI devices, but I don't know enough about x86 to say whether msr
>>instructions can execute out of userspace (or if we want them to...).
> MSR instructions cannot execute out of userspace, but the MSR driver
> might be possible to use. It's usually quite slow, however.
MSRs are used for setup, not for actual data.
Intel: magic MMIO address (readb)
AMD: magic PIO address (inl)
VIA: CPU instruction ('xstore')
Jeff
Deepak Saxena wrote:
> On Oct 15 2005, at 06:40, Jeff Garzik was caught saying:
>
>>Deepak Saxena wrote:
>>
>>>rewrite the damn thing to use the device model and have a rng
>>>device class with individual drivers for each RNG model, including
>>>IXP4xx. I'll keep the miscdev interface around but will add a
>>>new interface under /sys/class/rng that the userspace tools
>>>can transition to. Is this OK with folks?
>>
>>How does the hardware export RNG functionality? CPU insn? Magic memory
>>address? Can it be done 100% in userspace?
>
>
> It's a magic regsiter we just read/write and could be done in userspace.
> I also took a look at MPC85xx and it has the same sort of interface but
> also has an error interrupt capability. On second thought a class
> interface is overkill b/c there will only be one RNG per system, so
> I can just do something like watchdogs where we have a bunch of simple
> drivers exposing the same interface. We could do it in user space but
> then we have separate RNG implementations for x86 and !x86 and I'd
> rather not see that. Can we move the x86 code out to userspace and
> just let the daemon eat the numbers directly from HW? We can mmap()
> PCI devices, but I don't know enough about x86 to say whether msr
> instructions can execute out of userspace (or if we want them to...).
All of the hot path RNG stuff can and should be moved to userspace.
Right now the path is
kernel /dev/hwrandom -> rngd -> add /dev/random entropy
All three current vendors shown in hw_random.c are doable in userspace.
Intel uses MMIO, AMD uses PIO, and VIA uses a specialized CPU
instruction. As HPA mentioned, you can use the MSR driver for control.
Patches welcome! http://sf.net/projects/gkernel/
Jeff
Jeff Garzik wrote:
>
>> MSR instructions cannot execute out of userspace, but the MSR driver
>> might be possible to use. It's usually quite slow, however.
>
> MSRs are used for setup, not for actual data.
>
> Intel: magic MMIO address (readb)
> AMD: magic PIO address (inl)
> VIA: CPU instruction ('xstore')
>
For setup, the MSR driver is fine.
-hpa
On Oct 17 2005, at 19:31, Jeff Garzik was caught saying:
> >PCI devices, but I don't know enough about x86 to say whether msr
> >instructions can execute out of userspace (or if we want them to...).
>
> All of the hot path RNG stuff can and should be moved to userspace.
>
> Right now the path is
>
> kernel /dev/hwrandom -> rngd -> add /dev/random entropy
>
> All three current vendors shown in hw_random.c are doable in userspace.
> Intel uses MMIO, AMD uses PIO, and VIA uses a specialized CPU
> instruction. As HPA mentioned, you can use the MSR driver for control.
>
> Patches welcome! http://sf.net/projects/gkernel/
OK...I already did most of a rewrite keeping the driver in user space
and added support for IXP4xx and OMAP but will look at the msr driver.
However, looking at the MPC85xx and the Alchemy MIPs parts with RNGs,
they have interrupt sources for error conditions so those need to be
in kernel...
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
When law and duty are one, united by religion, you never become fully
conscious, fully aware of yourself. You are always a little less than
an individual. - Frank Herbert
On Oct 17 2005, at 18:00, Deepak Saxena was caught saying:
>
> OK...I already did most of a rewrite keeping the driver in user space
s/user/kernel/
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
When law and duty are one, united by religion, you never become fully
conscious, fully aware of yourself. You are always a little less than
an individual. - Frank Herbert
Deepak Saxena wrote:
> OK...I already did most of a rewrite keeping the driver in user space
> and added support for IXP4xx and OMAP but will look at the msr driver.
> However, looking at the MPC85xx and the Alchemy MIPs parts with RNGs,
> they have interrupt sources for error conditions so those need to be
> in kernel...
If its in kernel space, there is no need to use the MSR driver.
Jeff