[Qemu-devel] Error with Virtio DMA Remapping

Hi all, I am trying to use QEMU vIOMMU for virtio DMA remapping. When I run the VM, I get the following messages in stderr: qemu-system-x86_64: vtd_iommu_translate: detected translation failure (dev=01:00:00, iova=0x0) qemu-system-x86_64: New fault is not recorded due to compression of faults qe

Re: [Qemu-devel] Error: virtio_net: Too few free TX rings available.

Hello, On Thu, Jun 14, 2018 at 11:47:44AM +0800, Bo YU wrote: Hello, A am newbie to qemu. I am using qemu now: qemu-io --version qemu-io version 2.12.50 (v2.12.0-1296-g2ab09bf2f9-dirty) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers I have to talk about using qemu with l

[Qemu-devel] Error: virtio_net: Too few free TX rings available.

Hello, A am newbie to qemu. I am using qemu now: qemu-io --version qemu-io version 2.12.50 (v2.12.0-1296-g2ab09bf2f9-dirty) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers I have to talk about using qemu with libvirt recently libvirt deadlocked when libvirt fetching qemu c

[Qemu-devel] Error Msg on list.

Is this just me. I got the following message from 2 different SMTP servers. Google & Yahoo when sending via GIT mail. Mail to myself worked. Your message wasn't delivered to qemu-devel@nongnu.org because the address couldn't be found. Check for typos or unnecessary spaces and try again. John Br

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On Mon, Apr 24, 2017 at 06:33:26PM +0200, Geert Martin Ijewski wrote: > > We can have the existing qcrypto_init() call a qcrypto_random_init() > > method to do the one-time initialization task, since that's already > > required to run early in order to initialize gnutls when we use it. > > Wouldn'

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

> We can have the existing qcrypto_init() call a qcrypto_random_init() > method to do the one-time initialization task, since that's already > required to run early in order to initialize gnutls when we use it. Wouldn't it make sense to also move the unix initalization to that function? And what

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On Mon, Apr 24, 2017 at 04:42:38PM +0100, Peter Maydell wrote: > On 24 April 2017 at 16:41, Daniel P. Berrange wrote: > > We can have the existing qcrypto_init() call a qcrypto_random_init() > > method to do the one-time initialization task, since that's already > > required to run early in order

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On 24 April 2017 at 16:41, Daniel P. Berrange wrote: > We can have the existing qcrypto_init() call a qcrypto_random_init() > method to do the one-time initialization task, since that's already > required to run early in order to initialize gnutls when we use it. Yep, that would work, or initiali

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On Mon, Apr 24, 2017 at 03:05:40PM +0100, Peter Maydell wrote: > On 24 April 2017 at 14:57, Daniel P. Berrange wrote: > > This is the extent of gnutls's code in this area > > > > https://gitlab.com/gnutls/gnutls/blob/master/lib/nettle/sysrng-windows.c > > > > Our API has the same usage scenario as

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On 24 April 2017 at 14:57, Daniel P. Berrange wrote: > This is the extent of gnutls's code in this area > > https://gitlab.com/gnutls/gnutls/blob/master/lib/nettle/sysrng-windows.c > > Our API has the same usage scenario as this, hence my preference to mirror > what gnutls & other crypto libraries

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On Mon, Apr 24, 2017 at 02:52:30PM +0100, Peter Maydell wrote: > On 24 April 2017 at 14:36, Daniel P. Berrange wrote: > > FYI, both gnutls and openssl use these CryptAcquireContext/CryptGenRandom > > methods, so I'd prefer to stick with that. > > They probably need the full crypto API anyway, tho

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On 24 April 2017 at 14:36, Daniel P. Berrange wrote: > FYI, both gnutls and openssl use these CryptAcquireContext/CryptGenRandom > methods, so I'd prefer to stick with that. They probably need the full crypto API anyway, though... > It seems we merely need to set CRYPT_SILENT in the flags to pre

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On Mon, Apr 24, 2017 at 02:30:25PM +0100, Peter Maydell wrote: > On 24 April 2017 at 13:50, Daniel P. Berrange wrote: > > For subject line, better to describe the change made, rather than > > the problem. > > > > On Mon, Apr 24, 2017 at 02:17:56PM +0200, gm.ijew...@web.de wrote: > >> Now it calls

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

On 24 April 2017 at 13:50, Daniel P. Berrange wrote: > For subject line, better to describe the change made, rather than > the problem. > > On Mon, Apr 24, 2017 at 02:17:56PM +0200, gm.ijew...@web.de wrote: >> Now it calls CryptGenRandom() if is it compiled for windows. >> >> It might be possible

[Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

Now it calls CryptGenRandom() if is it compiled for windows. It might be possible to save the cryptographic provider in between invocations, e.g. by making it static -- I have no idea how computationally intensive that operation actually is. Signed-off-by: Geert Martin Ijewski

Re: [Qemu-devel] error: qcrypto_random_bytes() tried to read from /dev/[u]random, even on windows

For subject line, better to describe the change made, rather than the problem. On Mon, Apr 24, 2017 at 02:17:56PM +0200, gm.ijew...@web.de wrote: > Now it calls CryptGenRandom() if is it compiled for windows. > > It might be possible to save the cryptographic provider in between > invocations, e

[Qemu-devel] Error checking and qemu_thread_create

Hello. I want to make qemu_thread_create return a flag as described here (http://wiki.qemu-project.org/BiteSizedTasks), but I’m not sure how callers should behave if it fails. I could make it so they would call something like error_report() and then call abort(), but then it is almost a copy of

Re: [Qemu-devel] Error handling for KVM_GET_DIRTY_LOG

On 20.02.2017 14:46, Paolo Bonzini wrote: > > > On 16/02/2017 15:51, Janosch Frank wrote: >> While trying to fix a bug in the s390 migration code, I noticed that >> QEMU ignores practically all errors returned from that VM ioctl. QEMU >> behaves as specified in the KVM api and only processes -1 (

Re: [Qemu-devel] Error handling for KVM_GET_DIRTY_LOG

On 16/02/2017 15:51, Janosch Frank wrote: > While trying to fix a bug in the s390 migration code, I noticed that > QEMU ignores practically all errors returned from that VM ioctl. QEMU > behaves as specified in the KVM api and only processes -1 (-EPERM) as an > error. > > Unfortunately the docum

Re: [Qemu-devel] Error handling for KVM_GET_DIRTY_LOG

* Christian Borntraeger (borntrae...@de.ibm.com) wrote: > On 02/16/2017 03:51 PM, Janosch Frank wrote: > > While trying to fix a bug in the s390 migration code, I noticed that > > QEMU ignores practically all errors returned from that VM ioctl. QEMU > > behaves as specified in the KVM api and only

Re: [Qemu-devel] Error handling for KVM_GET_DIRTY_LOG

On 02/16/2017 03:51 PM, Janosch Frank wrote: > While trying to fix a bug in the s390 migration code, I noticed that > QEMU ignores practically all errors returned from that VM ioctl. QEMU > behaves as specified in the KVM api and only processes -1 (-EPERM) as an > error. > > Unfortunately the docu

[Qemu-devel] Error handling for KVM_GET_DIRTY_LOG

While trying to fix a bug in the s390 migration code, I noticed that QEMU ignores practically all errors returned from that VM ioctl. QEMU behaves as specified in the KVM api and only processes -1 (-EPERM) as an error. Unfortunately the documentation is wrong/old and KVM may return -EFAULT, -EINVA

Re: [Qemu-devel] Error on OpenBSD/macppc

On Thu, Feb 09, 2017 at 07:56:20AM +0100, Matthias Freitag wrote: > (qemu) unknown keycodes `macintosh_aliases(qwerty)', please report > to qemu-devel@nongnu.org > > Which i am doing with this email :) Thanks ! Could you tell us a few extra bits of info - What X server are you running on your

[Qemu-devel] Error on OpenBSD/macppc

(qemu) unknown keycodes `macintosh_aliases(qwerty)', please report to qemu-devel@nongnu.org Which i am doing with this email :)

Re: [Qemu-devel] error reporting in functions

Eric Blake writes: > On 10/12/2016 10:47 AM, Vladimir Sementsov-Ogievskiy wrote: >> HI all! >> >> My questions is: what are general recommendations in Qemu for return >> code, if we have Error **errp? >> What should I prefer: errp, duplicated by int return code, or void >> functions with errp? >

Re: [Qemu-devel] error reporting in functions

On 10/12/2016 10:47 AM, Vladimir Sementsov-Ogievskiy wrote: > HI all! > > My questions is: what are general recommendations in Qemu for return > code, if we have Error **errp? > What should I prefer: errp, duplicated by int return code, or void > functions with errp? Markus has already had severa

[Qemu-devel] error reporting in functions

HI all! My questions is: what are general recommendations in Qemu for return code, if we have Error **errp? What should I prefer: errp, duplicated by int return code, or void functions with errp? void + errp seems good, just to not duplicate things. But it has a disadvantage of necessity of

Re: [Qemu-devel] Error when attempting to perform TLS NBD connection

On Wed, Apr 06, 2016 at 12:40:44PM +0100, Alex Bligh wrote: > Daniel, > > On 6 Apr 2016, at 12:13, Daniel P. Berrange wrote: > > > So the problem turned out to be that the qemu-img program failed to > > call qcrypto_init(), so gnutls had not had its one-time initialization > > performed. This do

Re: [Qemu-devel] Error when attempting to perform TLS NBD connection

Daniel, On 6 Apr 2016, at 12:13, Daniel P. Berrange wrote: > So the problem turned out to be that the qemu-img program failed to > call qcrypto_init(), so gnutls had not had its one-time initialization > performed. This doesn't matter for gnutls 3.x but does for anything > older than that. I jus

Re: [Qemu-devel] Error when attempting to perform TLS NBD connection

On Tue, Apr 05, 2016 at 09:01:10PM +0100, Alex Bligh wrote: > When I attempt to connect via TLS like this (using today's qemu master): > >./qemu-img info --object > tls-creds-x509,id=tls0,dir=../certs,endpoint=client --image-opts > driver=nbd,host=127.0.0.1,port=,export=foo,tls-creds=tls

Re: [Qemu-devel] Error when attempting to perform TLS NBD connection

On Wed, Apr 06, 2016 at 10:22:45AM +0100, Alex Bligh wrote: > > On 6 Apr 2016, at 10:11, Daniel P. Berrange wrote: > > > Oh I'd be interested to know if the unit tests pass for you - can you > > run this > > > > make ./tests/test-crypto-tlssession ./tests/test-crypto-tlscredsx509 > > ./tests/

Re: [Qemu-devel] Error when attempting to perform TLS NBD connection

On 6 Apr 2016, at 10:11, Daniel P. Berrange wrote: > Oh I'd be interested to know if the unit tests pass for you - can you > run this > > make ./tests/test-crypto-tlssession ./tests/test-crypto-tlscredsx509 > ./tests/test-crypto-tlscredsx509 > ./tests/test-crypto-tlssession See below. They

Re: [Qemu-devel] Error when attempting to perform TLS NBD connection

On 6 Apr 2016, at 10:09, Daniel P. Berrange wrote: > I've just tested using your certs and they work correctly for me. I have > gnutls-3.4.10-1.fc23.x86_64 on Fedora 23, so either there's something > broken with gnutls 2.x compatibility in general, or there's a specific > bug in your exact vers

Re: [Qemu-devel] Error when attempting to perform TLS NBD connection

On Wed, Apr 06, 2016 at 10:09:07AM +0100, Daniel P. Berrange wrote: > On Tue, Apr 05, 2016 at 09:01:10PM +0100, Alex Bligh wrote: > > When I attempt to connect via TLS like this (using today's qemu master): > > > >./qemu-img info --object > > tls-creds-x509,id=tls0,dir=../certs,endpoint=clien

Re: [Qemu-devel] Error when attempting to perform TLS NBD connection

On Tue, Apr 05, 2016 at 09:01:10PM +0100, Alex Bligh wrote: > When I attempt to connect via TLS like this (using today's qemu master): > >./qemu-img info --object > tls-creds-x509,id=tls0,dir=../certs,endpoint=client --image-opts > driver=nbd,host=127.0.0.1,port=,export=foo,tls-creds=tls

[Qemu-devel] Error when attempting to perform TLS NBD connection

When I attempt to connect via TLS like this (using today's qemu master): ./qemu-img info --object tls-creds-x509,id=tls0,dir=../certs,endpoint=client --image-opts driver=nbd,host=127.0.0.1,port=,export=foo,tls-creds=tls0 (command line from Daniel over IRC) I get the rather opaque error:

Re: [Qemu-devel] Error handling in realize() methods

Paolo Bonzini writes: > On 10/12/2015 12:06, Markus Armbruster wrote: >> Paolo Bonzini writes: >> >>> On 09/12/2015 10:30, Markus Armbruster wrote: My current working assumption is that passing &error_fatal to memory_region_init_ram() & friends is okay even in realize() methods and >>

Re: [Qemu-devel] Error handling in realize() methods

On 10/12/2015 12:06, Markus Armbruster wrote: > Paolo Bonzini writes: > >> On 09/12/2015 10:30, Markus Armbruster wrote: >>> My current working assumption is that passing &error_fatal to >>> memory_region_init_ram() & friends is okay even in realize() methods and >>> their supporting code, exce

Re: [Qemu-devel] Error handling in realize() methods

On 10/12/2015 12:21, Dr. David Alan Gilbert wrote: > I guess the use of abort() could tell us > that - however it's a really big assumption that in an OOM case we'd > be able to dump the information. If it's not OOM, but just a multi-gigabyte allocation, we should. Paolo

Re: [Qemu-devel] Error handling in realize() methods

* Markus Armbruster (arm...@redhat.com) wrote: > Paolo Bonzini writes: > > > On 09/12/2015 10:30, Markus Armbruster wrote: > >> My current working assumption is that passing &error_fatal to > >> memory_region_init_ram() & friends is okay even in realize() methods and > >> their supporting code, e

Re: [Qemu-devel] Error handling in realize() methods

On 12/10/15 10:22, Markus Armbruster wrote: > Laszlo Ersek writes: > >> I've been following this discussion with great interest. >> >> My opinion should not be considered, because I won't be turning my >> opinion into new code, or an agreement to support / maintain code. :) >> >> My opinion is th

Re: [Qemu-devel] Error handling in realize() methods

Paolo Bonzini writes: > On 09/12/2015 10:30, Markus Armbruster wrote: >> My current working assumption is that passing &error_fatal to >> memory_region_init_ram() & friends is okay even in realize() methods and >> their supporting code, except when the allocation can be large. > > I suspect a lot

Re: [Qemu-devel] Error handling in realize() methods

"Dr. David Alan Gilbert" writes: > * Markus Armbruster (arm...@redhat.com) wrote: >> "Dr. David Alan Gilbert" writes: >> >> > * Markus Armbruster (arm...@redhat.com) wrote: >> >> In general, code running withing a realize() method should not exit() on >> >> error. Instad, errors should be prop

Re: [Qemu-devel] Error handling in realize() methods

Laszlo Ersek writes: > I've been following this discussion with great interest. > > My opinion should not be considered, because I won't be turning my > opinion into new code, or an agreement to support / maintain code. :) > > My opinion is that > - every single allocation needs to be checked rig

Re: [Qemu-devel] Error handling in realize() methods

On 09/12/2015 14:12, Dr. David Alan Gilbert wrote: >> > Even if we don't, we should use &error_abort, not &error_fatal >> > (programmer error---due to laziness---rather than user error). >> > &error_fatal should really be restricted to code that is running very >> > close to main(). > No, we used

Re: [Qemu-devel] Error handling in realize() methods

* Peter Maydell (peter.mayd...@linaro.org) wrote: > On 9 December 2015 at 10:29, Dr. David Alan Gilbert > wrote: > > (OK, to be honest I think we should protect every allocation - but I do > > have sympathy with the complexity/testing arguments). > > My view on this is that Linux overcommits, so

Re: [Qemu-devel] Error handling in realize() methods

* Paolo Bonzini (pbonz...@redhat.com) wrote: > > > On 09/12/2015 10:30, Markus Armbruster wrote: > > My current working assumption is that passing &error_fatal to > > memory_region_init_ram() & friends is okay even in realize() methods and > > their supporting code, except when the allocation can

Re: [Qemu-devel] Error handling in realize() methods

On 09/12/2015 10:30, Markus Armbruster wrote: > My current working assumption is that passing &error_fatal to > memory_region_init_ram() & friends is okay even in realize() methods and > their supporting code, except when the allocation can be large. I suspect a lot of memory_region_init_ram()s

Re: [Qemu-devel] Error handling in realize() methods

On 12/09/15 12:47, Peter Maydell wrote: > On 9 December 2015 at 10:29, Dr. David Alan Gilbert > wrote: >> (OK, to be honest I think we should protect every allocation - but I do >> have sympathy with the complexity/testing arguments). > > My view on this is that Linux overcommits, so the actual

Re: [Qemu-devel] Error handling in realize() methods

On 9 December 2015 at 10:29, Dr. David Alan Gilbert wrote: > (OK, to be honest I think we should protect every allocation - but I do > have sympathy with the complexity/testing arguments). My view on this is that Linux overcommits, so the actual likely way that "oops, out of memory" will manifest

Re: [Qemu-devel] Error handling in realize() methods

On 12/09/15 11:29, Dr. David Alan Gilbert wrote: > * Markus Armbruster (arm...@redhat.com) wrote: >> "Dr. David Alan Gilbert" writes: >> >>> * Markus Armbruster (arm...@redhat.com) wrote: In general, code running withing a realize() method should not exit() on error. Instad, errors shou

Re: [Qemu-devel] Error handling in realize() methods

* Markus Armbruster (arm...@redhat.com) wrote: > "Dr. David Alan Gilbert" writes: > > > * Markus Armbruster (arm...@redhat.com) wrote: > >> In general, code running withing a realize() method should not exit() on > >> error. Instad, errors should be propagated through the realize() > >> method.

Re: [Qemu-devel] Error handling in realize() methods

"Dr. David Alan Gilbert" writes: > * Markus Armbruster (arm...@redhat.com) wrote: >> In general, code running withing a realize() method should not exit() on >> error. Instad, errors should be propagated through the realize() >> method. Additionally, the realize() method should fail cleanly, >>

Re: [Qemu-devel] Error handling in realize() methods

* Markus Armbruster (arm...@redhat.com) wrote: > In general, code running withing a realize() method should not exit() on > error. Instad, errors should be propagated through the realize() > method. Additionally, the realize() method should fail cleanly, > i.e. carefully undo its side effects suc

[Qemu-devel] Error handling in realize() methods

In general, code running withing a realize() method should not exit() on error. Instad, errors should be propagated through the realize() method. Additionally, the realize() method should fail cleanly, i.e. carefully undo its side effects such as wiring of interrupts, mapping of memory, and so fo

Re: [Qemu-devel] error building latest QEMU

On 22.07.2015 19:57, Stefan Weil wrote: > Am 22.07.2015 um 18:01 schrieb Claudio Fontana: >> Hello, >> >> with the following configuration: >> >> ./configure --enable-fdt --disable-sdl --disable-vnc --enable-debug >> --disable-gtk --enable-kvm --target-list=aarch64-softmmu >> >> I get: >> >> vl.c:

Re: [Qemu-devel] error building latest QEMU

Am 22.07.2015 um 18:01 schrieb Claudio Fontana: Hello, with the following configuration: ./configure --enable-fdt --disable-sdl --disable-vnc --enable-debug --disable-gtk --enable-kvm --target-list=aarch64-softmmu I get: vl.c:2064:12: error: unused variable `err' [-Werror=unused-variable]

[Qemu-devel] error building latest QEMU

Hello, with the following configuration: ./configure --enable-fdt --disable-sdl --disable-vnc --enable-debug --disable-gtk --enable-kvm --target-list=aarch64-softmmu I get: vl.c:2064:12: error: unused variable `err' [-Werror=unused-variable] Error *err = NULL; ^ make: *** [vl.

[Qemu-devel] error

|fatal error: boost/algorithm/string.hpp: No such file or directory|

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

Peter Crosthwaite writes: > On Fri, Apr 11, 2014 at 11:41 PM, Markus Armbruster wrote: >> Peter Crosthwaite writes: >> >>> On Thu, Apr 10, 2014 at 1:48 AM, Markus Armbruster >>> wrote: I stumbled over this while trying to purge error_is_set() from the code. Here's how we c

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

On Fri, Apr 11, 2014 at 11:41 PM, Markus Armbruster wrote: > Peter Crosthwaite writes: > >> On Thu, Apr 10, 2014 at 1:48 AM, Markus Armbruster wrote: >>> I stumbled over this while trying to purge error_is_set() from the code. >>> >>> >>> Here's how we commonly use the Error API: >>> >>> Err

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

Peter Crosthwaite writes: > On Thu, Apr 10, 2014 at 1:48 AM, Markus Armbruster wrote: >> I stumbled over this while trying to purge error_is_set() from the code. >> >> >> Here's how we commonly use the Error API: >> >> Error *err = NULL; >> >> foo(arg, &err) >> if (err) { >>

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

On Thu, Apr 10, 2014 at 1:48 AM, Markus Armbruster wrote: > I stumbled over this while trying to purge error_is_set() from the code. > > > Here's how we commonly use the Error API: > > Error *err = NULL; > > foo(arg, &err) > if (err) { > goto out; > } > bar(arg, &err) >

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

Am 11.04.2014 um 10:28 hat Markus Armbruster geschrieben: > Kevin Wolf writes: > > > Am 09.04.2014 um 17:48 hat Markus Armbruster geschrieben: > >> I stumbled over this while trying to purge error_is_set() from the code. > >> > >> > >> Here's how we commonly use the Error API: > >> > >> Er

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

* Markus Armbruster (arm...@redhat.com) wrote: > "Dr. David Alan Gilbert" writes: > > > * Markus Armbruster (arm...@redhat.com) wrote: > >> I stumbled over this while trying to purge error_is_set() from the code. > > > >> Here's how we commonly use the Error API: > >> > >> Error *err = NULL;

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

Anthony Liguori writes: > The original visiting code was loosely based on ASN1 marshaling code > from Samba which used the "if error, bail out at the top" style of > error handling. > > As use of Error has evolved in QEMU, I agree that the paradigm of > "bail out as soon as you see an error and f

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

Kevin Wolf writes: > Am 09.04.2014 um 17:48 hat Markus Armbruster geschrieben: >> I stumbled over this while trying to purge error_is_set() from the code. >> >> >> Here's how we commonly use the Error API: >> >> Error *err = NULL; >> >> foo(arg, &err) >> if (err) { >> goto

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

"Dr. David Alan Gilbert" writes: > * Markus Armbruster (arm...@redhat.com) wrote: >> I stumbled over this while trying to purge error_is_set() from the code. > >> Here's how we commonly use the Error API: >> >> Error *err = NULL; >> >> foo(arg, &err) >> if (err) { >> goto ou

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

Am 09.04.2014 um 17:48 hat Markus Armbruster geschrieben: > I stumbled over this while trying to purge error_is_set() from the code. > > > Here's how we commonly use the Error API: > > Error *err = NULL; > > foo(arg, &err) > if (err) { > goto out; > } > bar(arg, &err

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

* Markus Armbruster (arm...@redhat.com) wrote: > I stumbled over this while trying to purge error_is_set() from the code. > Here's how we commonly use the Error API: > > Error *err = NULL; > > foo(arg, &err) > if (err) { > goto out; > } > bar(arg, &err) > if (err)

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

On Wed, Apr 9, 2014 at 8:48 AM, Markus Armbruster wrote: > I stumbled over this while trying to purge error_is_set() from the code. > > > Here's how we commonly use the Error API: > > Error *err = NULL; > > foo(arg, &err) > if (err) { > goto out; > } > bar(arg, &err) >

Re: [Qemu-devel] Error propagation in generated visitors and command marshallers

On 04/09/2014 09:48 AM, Markus Armbruster wrote: > I stumbled over this while trying to purge error_is_set() from the code. > > But: is it a good idea to have both patterns in the code? Should we > perhaps use the common pattern for visiting, too? Like this: > > visit_type_str(v, &foo, "fo

[Qemu-devel] Error propagation in generated visitors and command marshallers

I stumbled over this while trying to purge error_is_set() from the code. Here's how we commonly use the Error API: Error *err = NULL; foo(arg, &err) if (err) { goto out; } bar(arg, &err) if (err) { goto out; } This ensures that err is null on entry,

[Qemu-devel] Error occurs when "make efirom" in the patch "qemu/roms/"

Hi! I have trouble to build pex in qemu. When I run "make efirom" in the path qemu/roms/ I get errors as follows: arch/x86/core/x86_tcpip.c: Assembler messages: arch/x86/core/x86_tcpip.c:101: Error: no such instruction: `lodsll' arch/x86/core/x86_tcpip.c:103: Error: no such instruction: `lodsll'

Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

On 25 February 2014 09:19, Jobin Raju George wrote: > On Tue, Feb 25, 2014 at 2:42 PM, Peter Maydell > wrote: >> This looks like you didn't get qemu by cloning it from git (maybe you got >> a tarball?). That's fine but it's not what you said you did... >> > > Exactly! But is there a difference if

Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

On Tue, Feb 25, 2014 at 2:42 PM, Peter Maydell wrote: > On 25 February 2014 04:15, Jobin Raju George wrote: > > On Mon, Feb 24, 2014 at 5:54 PM, Peter Maydell > > > wrote: > >> Why not just do the git submodule command that the error message > >> from configure suggests? You don't need to manual

Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

On 25 February 2014 04:15, Jobin Raju George wrote: > On Mon, Feb 24, 2014 at 5:54 PM, Peter Maydell > wrote: >> Why not just do the git submodule command that the error message >> from configure suggests? You don't need to manually stick the tarball >> into the qemu tree like this. >> > When I d

Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

On Mon, Feb 24, 2014 at 5:54 PM, Peter Maydell wrote: > On 21 February 2014 21:41, Jobin Raju George wrote: > > To fix this issue: > > > > I cloned dtc from its repository and extracted the tarball to qemu/dtc/. > > Why not just do the git submodule command that the error message > from configure

Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

On 21 February 2014 21:41, Jobin Raju George wrote: > To fix this issue: > > I cloned dtc from its repository and extracted the tarball to qemu/dtc/. Why not just do the git submodule command that the error message from configure suggests? You don't need to manually stick the tarball into the qem

Re: [Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

To fix this issue: - I cloned dtc from its repositoryand extracted the tarball to qemu/dtc/. - Compiled dtc from source first using make - Restarted configuring qemu. The p

[Qemu-devel] Error compiling qemu from source on Ubuntu 12.10

I am trying to compile qemu from source to get my hands dirty with its development. I cloned the package from the repository. I extracted the tarball and started with the configuration using ./configure when I got the

Re: [Qemu-devel] Error handling in cpu_x86_create

On 2013-07-30 14:21, Igor Mammedov wrote: > On Tue, 30 Jul 2013 13:00:40 +0200 > Jan Kiszka wrote: > >> Hi Igor, >> >> just noticed by chance that error handling in cpu_x86_create is likely >> broken after your changes. Any error after cpu = ...object_new() will >> not properly release the CPU ob

Re: [Qemu-devel] Error handling in cpu_x86_create

On Tue, 30 Jul 2013 13:00:40 +0200 Jan Kiszka wrote: > Hi Igor, > > just noticed by chance that error handling in cpu_x86_create is likely > broken after your changes. Any error after cpu = ...object_new() will > not properly release the CPU object again nor report NULL to the caller. > That mea

[Qemu-devel] Error handling in cpu_x86_create

Hi Igor, just noticed by chance that error handling in cpu_x86_create is likely broken after your changes. Any error after cpu = ...object_new() will not properly release the CPU object again nor report NULL to the caller. That means errors should slip through, no? And cpu_x86_init looks similar.

Re: [Qemu-devel] error building x86_64-linux-user on i686 host

On Tue, May 28, 2013 at 02:11:21PM +0300, Michael S. Tsirkin wrote: > Building target x86_64-linux-user on a 32 bit host gives me > this error: > > [mst@robin x86_64-linux-user]$ cc -I/scm/qemu/tcg -I/scm/qemu/tcg/i386 > -I/scm/qemu/linux-headers -I. -I/scm/qemu -I/scm/qemu/include > -I/scm/qemu

[Qemu-devel] error building x86_64-linux-user on i686 host

Building target x86_64-linux-user on a 32 bit host gives me this error: [mst@robin x86_64-linux-user]$ cc -I/scm/qemu/tcg -I/scm/qemu/tcg/i386 -I/scm/qemu/linux-headers -I. -I/scm/qemu -I/scm/qemu/include -I/scm/qemu/linux-user -Ilinux-user -Werror -fPIE -DPIE -m32 -D_GNU_SOURCE -D_FILE_OFFSET_

[Qemu-devel] Error ** parameter conventions (was: [PATCH] qemu-sockets: Fix assertion failure)

[Note cc: Luiz] Kevin Wolf writes: > inet_connect_opts() tries all possible addrinfos returned by > getaddrinfo(). If one fails with an error, the next one is tried. In > this case, the Error should be discarded because the whole operation is > successful if another addrinfo from the list succee

[Qemu-devel] Error booting from USB Storage Device in QEMU-KVM GIT MASTER

Hi, I am unable to boot KVM using a usb flash drive. I'm using QEMU-KVM built from GIT MASTER as of this morning. Here's my QEMU-KVM startup options: qemu-system-x86_64 \ -curses \ -m 512 \ -snapshot \ -device piix3-usb-uhci \ -drive id=usbflash,file=

Re: [Qemu-devel] Error booting from USB Storage Device in QEMU-KVM GIT MASTER

Hi All, After booting KVM using the flash image as both a regular disk and a usb storage device.. /dev/sda is detected from ata1.00 and /dev/sdb is detected from usb-storage-1-1:1.0. Both /dev/sdX devices are the same disk / partition layout. --- Thanks, Dyweni On Thu, 19 Jan 2012 06

Re: [Qemu-devel] Error booting from USB Storage Device in QEMU-KVM GIT MASTER

On 01/19/12 13:57, Dyweni - Qemu-Devel wrote: > Hi, > > I am unable to boot KVM using a usb flash drive. I'm using QEMU-KVM built > from GIT MASTER as of this morning. > Start bios (version 1.6.3) > USB MSC vendor='QEMU' product='QEMU HARDDISK' rev='1.0.' type=0 removable=0 > Unable to configure

Re: [Qemu-devel] Error while booting

On Thu, Dec 8, 2011 at 6:20 AM, Kevin Wolf wrote: > Am 07.12.2011 17:26, schrieb sparsh mittal: > > I use version 0.15 of qemu with marss cycle-accurate simulator. > > > > After making checkpoints in an image, I get this error, while trying to > > boot it (i.e. not using loadvm to run checkpoint,

Re: [Qemu-devel] Error while booting

Am 07.12.2011 17:26, schrieb sparsh mittal: > I use version 0.15 of qemu with marss cycle-accurate simulator. > > After making checkpoints in an image, I get this error, while trying to > boot it (i.e. not using loadvm to run checkpoint, but just starting the > image). > > This kernel requires an

[Qemu-devel] Error while booting

I use version 0.15 of qemu with marss cycle-accurate simulator. After making checkpoints in an image, I get this error, while trying to boot it (i.e. not using loadvm to run checkpoint, but just starting the image). This kernel requires an x86-64 CPU, but only detected an i686 CPU. Unable to boot

Re: [Qemu-devel] error when doing passthrough of bcm netextreme II 10 G device

On 2011-07-21 20:19, Sinha, Ani wrote: > Hi Folks : > > I am trying to assinga bcm netextreme II 10 G eth device to a guest using > PCI passthrough in QEMU. > > 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57711 > 10-Gigabit PCIe > 01:00.1 Ethernet controller: Broadcom Corpo

[Qemu-devel] error when doing passthrough of bcm netextreme II 10 G device

Hi Folks : I am trying to assinga bcm netextreme II 10 G eth device to a guest using PCI passthrough in QEMU. 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57711 10-Gigabit PCIe 01:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM57711 10-Gigabit PCIe qemu> d

Re: [Qemu-devel] error "kvm: virtio: trying to map MMIO memory"

Thank you for your help, I have been able to see where was the bug ! Indeed, I was losing some address values along the way in a callback function whereas I thought they were kept memorized. Regards Stéphanie

Re: [Qemu-devel] error "kvm: virtio: trying to map MMIO memory"

2011/7/17 Stéphanie Ouillon : > I have been facing a problem for 3-4 days with my virtio network device > driver in qemu: when I load the driver, I get the following error: > kvm: virtio: trying to map MMIO memory [...] > Would anybody have a clue about what kind of bug would provoke this error in

[Qemu-devel] error "kvm: virtio: trying to map MMIO memory"

Hello, I am porting virtio device drivers for DragonFly BSD for a GSoC project. [1] I have been facing a problem for 3-4 days with my virtio network device driver in qemu: when I load the driver, I get the following error: kvm: virtio: trying to map MMIO memory And then the machine crashes im

[Qemu-devel] Error handling while loading ROM

Hi all, I'm new to the list, so hopefully I'm not retracing old ground (I did try to search the archives, but maybe I missed something). The problem I have is that when using the Stellarris ARMv7M target if I load an ELF file as my kernel, and some of the ELF segments are outside the range of mem

[Qemu-devel] Error running qemu on powerpc

Hi, I have installed qemu on x86 system. I downloaded debian-powerpc image from http://people.debian.org/~aurel32/qemu/powerpc/ and used it with "qemu-system-ppc". This is the cpuinfo of the guest os (debian-507-powerpc (2.6.26-1-powerpc) ) processor: 0 cpu: 740/750 temperature

  1   2   >