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
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 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 to pass
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 03/01/2013 10:34 PM, Stefan Berger wrote:
On 03/01/2013 10:17 PM, Anthony Liguori wrote:
Stefan Berger stef...@linux.vnet.ibm.com writes:
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake
On 03/01/2013 08:13 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com 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.
[adding libvirt]
On 03/03/2013 02:05 PM, Anthony Liguori wrote:
Paolo Bonzini pbonz...@redhat.com 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
Eric Blake ebl...@redhat.com writes:
[adding libvirt]
On 03/03/2013 02:05 PM, Anthony Liguori wrote:
Paolo Bonzini pbonz...@redhat.com 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
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 libvirt
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
Paolo Bonzini pbonz...@redhat.com 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
Stefan Berger stef...@linux.vnet.ibm.com 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
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?
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
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 things:
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
Eric Blake ebl...@redhat.com 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
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
The guest kernel already provides the PRNG itself. We have been over this...
Stefan Berger stef...@linux.vnet.ibm.com 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
On 03/01/2013 03:04 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com 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
Stefan Berger stef...@linux.vnet.ibm.com writes:
On 03/01/2013 03:04 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com 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
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, then we
On 03/01/13 21:04, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com 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
Eric Blake ebl...@redhat.com 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
Peter Krempa pkre...@redhat.com writes:
On 03/01/13 21:04, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com 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
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com 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
Eric Blake ebl...@redhat.com writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com 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
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
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com 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
Eric Blake ebl...@redhat.com 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
Stefan Berger stef...@linux.vnet.ibm.com writes:
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 03/01/2013 02:08 PM, Anthony Liguori wrote:
You can pass chardevs to
On 03/01/2013 10:17 PM, Anthony Liguori wrote:
Stefan Berger stef...@linux.vnet.ibm.com writes:
On 03/01/2013 06:59 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 03/01/2013 04:05 PM, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 03/01/2013 02:08 PM,
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:
-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 entropy
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 to use these
-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 by
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 properties -
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() ...
-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 command
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
-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 let
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
-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 broken and
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
Note, I think
-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
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 stream
47 matches
Mail list logo
