From: Pan Nengyuan
The BDRVNBDState cleanup code is common in two places, add
nbd_clear_bdrvstate() function to do these cleanups.
Signed-off-by: Stefano Garzarella
Signed-off-by: Pan Nengyuan
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
v3:
- new patch, split form 2/2 patch (suggested by
From: Pan Nengyuan
This series add a new function to do the common cleanups, and fix a memory
leak in nbd_open when nbd_client_connect returns error status.
---
Changes v2 to v1:
- add a new function to do the common cleanups (suggested by Stefano
Garzarella).
---
Changes v3 to v2:
- split in
From: Pan Nengyuan
In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to
reproduce:
1. run qemu-iotests as follow and check the result with asan:
./check -raw 143
Following is the asan output backtrack:
Direct leak of
From: Pan Nengyuan
In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to
reproduce:
1. run qemu-iotests as follow and check the result with asan:
./check -raw 143
Following is the asan output backtrack:
Direct leak of
From: Pan Nengyuan
The BDRVNBDState cleanup code is common in two places, add
nbd_clear_bdrvstate() function to do these cleanups.
Signed-off-by: Stefano Garzarella
Signed-off-by: Pan Nengyuan
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
v3:
- new patch, split form 2/2 patch (suggested by
From: Pan Nengyuan
This series add a new function to do the common cleanups, and fix a memory
leak in nbd_open when nbd_client_connect returns error status.
---
Changes v2 to v1:
- add a new function to do the common cleanups (suggested by Stefano
Garzarella).
---
Changes v3 to v2:
- split in
On Wed, Dec 04, 2019 at 04:46:12PM +0100, Thomas Huth wrote:
> Some tests create huge (but sparse) files, and to be able to run those
> tests in certain limited environments (like CI containers), we have to
> check for the possibility to create such files first. Thus let's introduce
> a common
On Wed, Dec 04, 2019 at 04:46:18PM +0100, Thomas Huth wrote:
> Travis recently added the possibility to test on these architectures,
> too, so let's enable them in our travis.yml file to extend our test
> coverage.
>
> Unfortunately, the libssh in this Ubuntu version (bionic) is in a pretty
>
On Wed, Dec 04, 2019 at 04:46:11PM +0100, Thomas Huth wrote:
> Travis recently added build hosts for arm64, ppc64le and s390x, so
> this is a welcome addition to our Travis testing matrix.
>
> Unfortunately, the builds are running in quite restricted LXD containers
> there, for example it is not
We seem to be settling out to either fsdev/virtiofsd or tools/virtiofsd
with tools picking up some speed as people seem to want to put a bunch
of other stuff in there.
Unless anyone shouts really loud, I'll work on making it
tools/virtiofsd.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com
On 12/4/19 4:46 PM, Thomas Huth wrote:
Test 079 fails in the arm64, s390x and ppc64le LXD containers on Travis
(which we will hopefully enable in our CI soon). These containers
apparently do not allow large files to be created. Test 079 tries to
create a 4G sparse file, which is apparently
On 12/4/19 4:46 PM, Thomas Huth wrote:
Test 060 fails in the arm64, s390x and ppc64le LXD containers on Travis
(which we will hopefully enable in our CI soon). These containers
apparently do not allow large files to be created. The repair process
in test 060 creates a file of 64 GiB, so test
test-util-filemonitor fails in restricted non-x86 Travis containers
since they apparently blacklisted some required system calls there.
Let's simply skip the test if we detect such an environment.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
Signed-off-by: Thomas Huth
---
From: Alex Bennée
Our docker infrastructure isn't quite as multiarch as we would wish so
let's allow the user to disable it if they want. This will allow us to
use still run check-tcg on non-x86 CI setups.
Signed-off-by: Alex Bennée
Reviewed-by: Stefan Weil
Signed-off-by: Thomas Huth
---
On 12/4/19 4:46 PM, Thomas Huth wrote:
Some tests create huge (but sparse) files, and to be able to run those
tests in certain limited environments (like CI containers), we have to
check for the possibility to create such files first. Thus let's introduce
a common function to check for large
In certain environments like restricted containers, we can not create
huge test images. To be able to use "make check" in such container
environments, too, let's skip the hd-geo-test instead of failing when
the test images could not be created.
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by:
Test 079 fails in the arm64, s390x and ppc64le LXD containers on Travis
(which we will hopefully enable in our CI soon). These containers
apparently do not allow large files to be created. Test 079 tries to
create a 4G sparse file, which is apparently already too big for these
containers, so check
Travis recently added build hosts for arm64, ppc64le and s390x, so
this is a welcome addition to our Travis testing matrix.
Unfortunately, the builds are running in quite restricted LXD containers
there, for example it is not possible to create huge files there (even
if they are just sparse), and
Travis recently added the possibility to test on these architectures,
too, so let's enable them in our travis.yml file to extend our test
coverage.
Unfortunately, the libssh in this Ubuntu version (bionic) is in a pretty
unusable Frankenstein state and libspice-server-dev is not available here,
Test 060 fails in the arm64, s390x and ppc64le LXD containers on Travis
(which we will hopefully enable in our CI soon). These containers
apparently do not allow large files to be created. The repair process
in test 060 creates a file of 64 GiB, so test first whether such large
files are possible
Some tests create huge (but sparse) files, and to be able to run those
tests in certain limited environments (like CI containers), we have to
check for the possibility to create such files first. Thus let's introduce
a common function to check for large files, and replace the already
existing
Vladimir Sementsov-Ogievskiy writes:
> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
> can't see this additional information, because
On 12/4/19 7:28 AM, Kevin Wolf wrote:
Am 04.12.2019 um 09:17 hat Gerd Hoffmann geschrieben:
Hi,
| ...
+- qemu-edid
Has its own MAINTAINERS section, together with hw/display/edit* and
include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good
idea. Gerd?
On 12/4/19 1:43 AM, Markus Armbruster wrote:
+- qemu-img
| +- qemu-img.c
Perhaps this one can all go into existing block/, similar to how
pr-manager-helper.c is in scsi/, and virtfs-proxy-helper.c is in fsdev/.
Up to the block maintainers, of course.
+- qemu-nbd
| +-
On 27/11/2019 09.50, Thomas Huth wrote:
> On 25/11/2019 11.28, Alex Bennée wrote:
>>
>> Alex Bennée writes:
>>
>>> Thomas Huth writes:
>>>
Travis recently added build hosts for arm64, ppc64le and s390x, so
this is a welcome addition to our Travis testing matrix.
On 04/12/2019 14.28, Kevin Wolf wrote:
> Am 04.12.2019 um 09:17 hat Gerd Hoffmann geschrieben:
>> Hi,
>>
| ...
+- qemu-edid
>>>
>>> Has its own MAINTAINERS section, together with hw/display/edit* and
>>> include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good
Am 04.12.2019 um 09:17 hat Gerd Hoffmann geschrieben:
> Hi,
>
> > > | ...
> > > +- qemu-edid
> >
> > Has its own MAINTAINERS section, together with hw/display/edit* and
> > include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good
> > idea. Gerd?
>
> Sort-of makes
Am 04.12.2019 um 13:18 hat Vladimir Sementsov-Ogievskiy geschrieben:
> There is a question to discuss.
>
> We need to make an option to allow nbd-reconnect loop on nbd-open.
> For example, add optional nbd blockdev option open-reconnect-delay, to
> make it possible to start qemu with specified
"Dr. David Alan Gilbert" writes:
> So what do you think of Paolo's suggestion of putting virtiofsd in
> fsdev (mkdir fsdev/9p && mv fsdev/* fsdev/9p && mkdir fsdev/virtiofsd )
No objections.
Flatter: fsdev-9p/ and fsdev-virtio/. Matter of taste.
Hi Eric!
There is a question to discuss.
We need to make an option to allow nbd-reconnect loop on nbd-open.
For example, add optional nbd blockdev option open-reconnect-delay, to
make it possible to start qemu with specified nbd connection, when nbd
server is down, and make several tries to
* Markus Armbruster (arm...@redhat.com) wrote:
> Daniel P. Berrangé writes:
>
> > On Tue, Dec 03, 2019 at 11:06:44AM +, Peter Maydell wrote:
> >> On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert
> >> wrote:
> >> >
> >> > We seem to be coming to the conclusion something that:
> >> >
> >>
Hi,
> > | ...
> > +- qemu-edid
>
> Has its own MAINTAINERS section, together with hw/display/edit* and
> include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good
> idea. Gerd?
Sort-of makes sense. My personal preference would be a tools/ directory
for all those
32 matches
Mail list logo
