On 02/25/13 10:42, Peter Krempa wrote:
On 02/23/13 00:33, Eric Blake wrote:
> On 02/21/2013 07:47 AM, Peter Krempa wrote:
>> This patch adds basic configuration support for the RNG device suporting
>
> s/suporting/supporting/
>
>> the virtio model with the "random" and "egd" backend types as
described
>> in the schema in the previous patch.
>> ---
>>
>> Notes:
>> Version 2:
>> - fix a ton of memory leaks (I assumed that virXMLGetProp
>> returns static strings)
>> - Add new device type to even more places
>> - Fix error message c&p error
>> - Fix memleak in RNGDef free func
>
...
>> @@ -10601,6 +10734,22 @@ virDomainDefParseXML(virCapsPtr caps,
>> }
>> }
>>
>> + /* Parse the RNG device */
>> + if ((n = virXPathNodeSet("./devices/rng", ctxt, &nodes)) <
0)
>> + goto error;
>> +
>> + if (n > 1) {
>> + virReportError(VIR_ERR_XML_ERROR, "%s",
>> + _("only a single RNG device is supported"));
>
> Is this an inherent limit of qemu? For that matter, is it an inherent
> limit, and no hypervisor can ever support more than one? In the bare
> metal case, can't you plug in multiple rng hardware dongles?
AFAIK qemu is able to support multiple RNG devices but I didn't find
that particularly useful. I will follow up with a patch that will add
support for more than one RNG device, although I don't think it will be
used much.
I hacked up the patch to add support for multiple RNG's. qemu appears to
support the device just fine.
As of guest support it seems that it triggers a 100% reproducible kernel
panic on linux guest when attempting to read from a machine with two
virtio-rng devices. I filed a bug to track this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=915335
Peter