Dave Gilbert hit the following virtio migration error message today
and asked me if it was a known bug:
virtio-rng: VQ 0 size 0x8 < last_avail_idx 0x21 - used_idx 0x22
It looks like a legitimate new bug. This error occurred with postcopy
live migration and no rng backend (just -device virtio-rng-
On (Fri) 01 Mar 2013 [10:51:33], Paolo Bonzini wrote:
> Il 01/03/2013 01:36, Eric Blake ha scritto:
> > For fd passing to work, we have to use qemu_open() instead of raw
> > open(). Is there any way to enforce that all files being opened by qemu
> > go through the appropriate qemu_open() wrapper?
On 03/02/2013 04:23 AM, Paolo Bonzini wrote:
> Il 02/03/2013 04:13, Anthony Liguori ha scritto:
>> There is no valid use-case of rng-random other than using /dev/random.
>> In fact, it was probably a mistake to even allow a filename to be
>> specified because it lets people do silly things (like /d
On 03/04/2013 03:24 PM, Anthony Liguori wrote:
>> Then libvirt should also make sure that the XML we allow for non-egd
>> virtio-rng is restricted to the two filenames that won't cause a qemu
>> warning, or even modify the XML to not expose a filename in the first
>> place. We haven't released lib
Eric Blake writes:
> [adding libvirt]
>
> On 03/03/2013 02:05 PM, Anthony Liguori wrote:
>> Paolo Bonzini writes:
>>
>>> Il 02/03/2013 04:13, Anthony Liguori ha scritto:
There is no valid use-case of rng-random other than using /dev/random.
In fact, it was probably a mistake to even a
[adding libvirt]
On 03/03/2013 02:05 PM, Anthony Liguori wrote:
> Paolo Bonzini writes:
>
>> Il 02/03/2013 04:13, Anthony Liguori ha scritto:
>>> There is no valid use-case of rng-random other than using /dev/random.
>>> In fact, it was probably a mistake to even allow a filename to be
>>> speci
On 03/01/2013 08:13 PM, Anthony Liguori wrote:
> Eric Blake writes:
>
>> On 03/01/2013 04:59 PM, Anthony Liguori wrote:
>>> I said this when seccomp was first introduced and I'll say it again.
>>> blacklisting open() is a bad idea. DAC and MAC already exist and solve
>>> this problem. We've got
On 03/01/2013 10:34 PM, Stefan Berger wrote:
On 03/01/2013 10:17 PM, Anthony Liguori wrote:
Stefan Berger writes:
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 02:08 PM, Anthony Liguo
On 03/04/2013 05:29 AM, Daniel P. Berrange wrote:
On Fri, Mar 01, 2013 at 04:14:40PM -0700, Eric Blake wrote:
I understand the reason that fdsets exist (because NFS is stupid and
doesn't support labeling). But we aren't doing dynamic labeling of
/dev/random and I strongly suspect it's not on
On Fri, Mar 01, 2013 at 04:14:40PM -0700, Eric Blake wrote:
> > I understand the reason that fdsets exist (because NFS is stupid and
> > doesn't support labeling). But we aren't doing dynamic labeling of
> > /dev/random and I strongly suspect it's not on NFS anyway.
> >
> > So why are we trying t
On (Fri) 01 Mar 2013 [10:51:33], Paolo Bonzini wrote:
> Il 01/03/2013 01:36, Eric Blake ha scritto:
> > For fd passing to work, we have to use qemu_open() instead of raw
> > open(). Is there any way to enforce that all files being opened by qemu
> > go through the appropriate qemu_open() wrapper?
Stefan Berger writes:
> It depends on what one defends against. If a jail-break succeeds and
> open() is disabled, then that attack surfaces was effectively reduced.
> It's hard to say whether opening files within libvirt could then allow
> new exploits.
Well, in the very least, libvirt is do
Paolo Bonzini writes:
> Il 02/03/2013 04:13, Anthony Liguori ha scritto:
>> There is no valid use-case of rng-random other than using /dev/random.
>> In fact, it was probably a mistake to even allow a filename to be
>> specified because it lets people do silly things (like /dev/urandom).
>>
>> I
Il 02/03/2013 04:13, Anthony Liguori ha scritto:
> There is no valid use-case of rng-random other than using /dev/random.
> In fact, it was probably a mistake to even allow a filename to be
> specified because it lets people do silly things (like /dev/urandom).
>
> If you want anything other than
On 03/01/2013 10:17 PM, Anthony Liguori wrote:
Stefan Berger writes:
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 02:08 PM, Anthony Liguori wrote:
You can pass chardevs to the egd bac
Stefan Berger writes:
> On 03/01/2013 06:59 PM, Anthony Liguori wrote:
>> Eric Blake writes:
>>
>>> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake writes:
> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>
You can pass chardevs to the egd backend. It's rea
Eric Blake writes:
> On 03/01/2013 04:59 PM, Anthony Liguori wrote:
>> I said this when seccomp was first introduced and I'll say it again.
>> blacklisting open() is a bad idea. DAC and MAC already exist and solve
>> this problem. We've got filesystem namespaces too.
>
> Let's explore that idea
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake writes:
On 03/01/2013 02:08 PM, Anthony Liguori wrote:
You can pass chardevs to the egd backend. It's really not a good idea
to pass a fd via rng-rangom.
Why not?
On 03/01/2013 04:59 PM, Anthony Liguori wrote:
> I said this when seccomp was first introduced and I'll say it again.
> blacklisting open() is a bad idea. DAC and MAC already exist and solve
> this problem. We've got filesystem namespaces too.
Let's explore that idea a bit further. What happens
Eric Blake writes:
> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
>> Eric Blake writes:
>>
>>> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>>>
>> You can pass chardevs to the egd backend. It's really not a good idea
>> to pass a fd via rng-rangom.
>>>
>>> Why not? If you are runn
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
> Eric Blake writes:
>
>> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>>
> You can pass chardevs to the egd backend. It's really not a good idea
> to pass a fd via rng-rangom.
>>
>> Why not? If you are running a single guest, why can't l
Peter Krempa writes:
> On 03/01/13 21:04, Anthony Liguori wrote:
>> Eric Blake writes:
>>
>>> Stefan Berger and I discovered on IRC that virtio-rng is unable to
>>> support fd passing. We attempted:
>>>
>>> qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
>>> -object rng-ra
Eric Blake writes:
> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>
You can pass chardevs to the egd backend. It's really not a good idea
to pass a fd via rng-rangom.
>
> Why not? If you are running a single guest, why can't libvirt pass that
> one guest an fd instead of making qemu
On 03/01/13 21:04, Anthony Liguori wrote:
Eric Blake writes:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
-object rng-random,id=rng0,filename=/dev/fdset/4 -device
vir
On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>>> You can pass chardevs to the egd backend. It's really not a good idea
>>> to pass a fd via rng-rangom.
Why not? If you are running a single guest, why can't libvirt pass that
one guest an fd instead of making qemu open() the file?
>>
>> Fine,
Stefan Berger writes:
> On 03/01/2013 03:04 PM, Anthony Liguori wrote:
>> Eric Blake writes:
>>
>>> Stefan Berger and I discovered on IRC that virtio-rng is unable to
>>> support fd passing. We attempted:
>>>
>>> qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
>>> -object
Il 01/03/2013 21:13, Stefan Berger ha scritto:
> On 03/01/2013 02:37 PM, H. Peter Anvin wrote:
>> On 02/28/2013 04:36 PM, Eric Blake wrote:
>>> Stefan Berger and I discovered on IRC that virtio-rng is unable to
>>> support fd passing. We attempted:
>>>
>>> qemu-system-x86_64 ... -add-fd
>>> set=4,
On 03/01/2013 03:04 PM, Anthony Liguori wrote:
Eric Blake writes:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
-object rng-random,id=rng0,filename=/dev/fdset/4 -devic
The guest kernel already provides the PRNG itself. We have been over this...
Stefan Berger wrote:
>On 03/01/2013 02:37 PM, H. Peter Anvin wrote:
>> On 02/28/2013 04:36 PM, Eric Blake wrote:
>>> Stefan Berger and I discovered on IRC that virtio-rng is unable to
>>> support fd passing. We attemp
On 03/01/2013 02:37 PM, H. Peter Anvin wrote:
On 02/28/2013 04:36 PM, Eric Blake wrote:
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd
set=4,fd=34,opaque=RDONLY:/dev/urandom
^
Eric Blake writes:
> Stefan Berger and I discovered on IRC that virtio-rng is unable to
> support fd passing. We attempted:
>
> qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
> -object rng-random,id=rng0,filename=/dev/fdset/4 -device
> virtio-rng-pci,rng=rng0,bus=pci.0,add
On 02/28/2013 04:36 PM, Eric Blake wrote:
> Stefan Berger and I discovered on IRC that virtio-rng is unable to
> support fd passing. We attempted:
>
> qemu-system-x86_64 ... -add-fd
> set=4,fd=34,opaque=RDONLY:/dev/urandom
> -object rng-random,id=rng0,fil
Il 01/03/2013 01:36, Eric Blake ha scritto:
> For fd passing to work, we have to use qemu_open() instead of raw
> open(). Is there any way to enforce that all files being opened by qemu
> go through the appropriate qemu_open() wrapper?
>
> Meanwhile, we have a quandary on the libvirt side of thin
Stefan Berger and I discovered on IRC that virtio-rng is unable to
support fd passing. We attempted:
qemu-system-x86_64 ... -add-fd set=4,fd=34,opaque=RDONLY:/dev/urandom
-object rng-random,id=rng0,filename=/dev/fdset/4 -device
virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x6
qemu-system-x86_64: -devi
On (Tue) Nov 17 2009 [11:10:32], Ian Molton wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Amit Shah wrote:
> > (Any reason to take this off-list?)
>
> None other than hitting reply rather than reply-all. CCing list once
> more :-)
>
> >> Either way, you still need to specify the p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amit Shah wrote:
> (Any reason to take this off-list?)
None other than hitting reply rather than reply-all. CCing list once
more :-)
>> Either way, you still need to specify the properties - they've just
>> moved into the console driver in your patch
On (Mon) Nov 16 2009 [17:58:22], Ian Molton wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Gerd Hoffmann wrote:
>
> > Maybe ...
> >
> >-chardev socket,id=egd,host=egd.domain.tld,port=whatever
> >-device virtio-rng,chardev=egd
>
> I've had a go at modifying virtio-console.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Lokier wrote:
> Ian Molton wrote:
>
> With VMs, in some circumstances it might be preferable to trust the
> host when it says it's providing already-tested entropy. After all
> the host has total control over the guest anyway, and the host entro
Ian Molton wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jamie Lokier wrote:
> > Ian Molton wrote:
> >> Heres my patch to virtio-console. The device is now specified like this:
> >>
> >> - -chardev file,path=/path/to/testfile,id=test
> >> - -device virtio-console-pci,chardev=test
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Lokier wrote:
> Ian Molton wrote:
>> Heres my patch to virtio-console. The device is now specified like this:
>>
>> - -chardev file,path=/path/to/testfile,id=test
>> - -device virtio-console-pci,chardev=test
Note, I think the patch above is brok
Ian Molton wrote:
> Heres my patch to virtio-console. The device is now specified like this:
>
> - -chardev file,path=/path/to/testfile,id=test
> - -device virtio-console-pci,chardev=test
It'd be nice if some options on the qemu command line (or config file)
resulted in the guest kernel getting e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerd Hoffmann wrote:
> Maybe ...
>
>-chardev socket,id=egd,host=egd.domain.tld,port=whatever
>-device virtio-rng,chardev=egd
I've had a go at modifying virtio-console.c to use these semantics,
attached below. I'd appreciate it if you could l
On 11/16/09 13:28, Ian Molton wrote:
I've done something similar (below)
My commandline looks like:
- -virtiorng dev=/dev/foo,rate=1234
I added some properties to my driver which are obviously then filled in
from the options code, and I do my init like this:
There is no need for a new -virt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerd Hoffmann wrote:
> Hi,
Hi!
Thanks for your reply - I should have posted to say I'd partially solved
this. I have a question though,
> Use a chardev property (look at serial.c, "isa-serial" device).
>
> Then you'll configure it on the qemu com
Hi,
in qdev_init_chardev() the return value is picked based upon the name of
the device. For now, I've added a third 'if clause' to match for my
driver and pass through the CharDriverState * fron vl.c for my rng
driver, however I'd like to solve this properly.
Ignore qdev_init_chardev() ...
> I'm writing a virtio-rng host-side driver for qemu-kvm, and I've got
> something up and running that works, and will pass data gathered from a
> char device on the host through to the virtio-rng driver on a guest copy
> of linux.
Why do you need a special device? Isn't a regular serial data stre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi folks,
I'm writing a virtio-rng host-side driver for qemu-kvm, and I've got
something up and running that works, and will pass data gathered from a
char device on the host through to the virtio-rng driver on a guest copy
of linux.
Ultimately it'll
47 matches
Mail list logo
