On Tue, Sep 22, 2020 at 12:16 PM Daniel P. Berrangé wrote:
>
> 2 years back I proposed dropping the sheepdog mailing list from the
> MAINTAINERS file, but somehow the patch never got picked up:
>
> https://lists.gnu.org/archive/html/qemu-block/2018-03/msg01048.html
>
> So here I am with the
This generally does not work on non-file protocols. It is better to
create the image with the final name from the start, and most tests do
this already. Let 046 follow suit.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/046 | 5 +++--
tests/qemu-iotests/046.out | 2 +-
2 files changed,
Otherwise, exports and block devices are not properly shut down and
closed, unless the users explicitly issues blockdev-del and
block-export-del commands for each of them.
Signed-off-by: Max Reitz
---
storage-daemon/qemu-storage-daemon.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 22/09/2020 12.49, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> configure | 34 ++
> meson.build | 6 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/configure b/configure
> index ce27eafb0a..21c31e4694 100755
> --- a/configure
> +++
Thomas Huth writes:
> On 22/09/2020 11.01, Daniel P. Berrangé wrote:
> [...]
>> Does someone have a compelling reason for QEMU to keep supporting
>> this driver, other than the fact that it already exists ?
>>
>> If not, it looks like a candidate for deprecating in QEMU with a
>> view to later
This thread from a little over a year ago:
http://lists.wpkg.org/pipermail/sheepdog/2019-March/thread.html
states that sheepdog is no longer actively developed. The only mentioned
users are some companies who are said to have it for legacy reasons with
plans to replace it by Ceph. There is
On 22/09/2020 18.16, Daniel P. Berrangé wrote:
> The sheepdog mailing list is setup to stop and queue messages from
> non-subscribers, pending moderator approval. Unfortunately it seems
> that the moderation queue is not actively dealt with. Even when messages
> are approved, the sender is never
22.09.2020 19:16, Daniel P. Berrangé wrote:
This thread from a little over a year ago:
http://lists.wpkg.org/pipermail/sheepdog/2019-March/thread.html
states that sheepdog is no longer actively developed. The only mentioned
users are some companies who are said to have it for legacy reasons
On Tue, Sep 22, 2020 at 1:43 PM Daniel P. Berrangé wrote:
>
> On Tue, Sep 22, 2020 at 01:09:06PM -0400, Neal Gompa wrote:
> > On Tue, Sep 22, 2020 at 12:16 PM Daniel P. Berrangé
> > wrote:
> > >
> > > 2 years back I proposed dropping the sheepdog mailing list from the
> > > MAINTAINERS file,
On Tue, Sep 22, 2020 at 01:09:06PM -0400, Neal Gompa wrote:
> On Tue, Sep 22, 2020 at 12:16 PM Daniel P. Berrangé
> wrote:
> >
> > 2 years back I proposed dropping the sheepdog mailing list from the
> > MAINTAINERS file, but somehow the patch never got picked up:
> >
> >
On Sep 22 08:31, Keith Busch wrote:
> On Tue, Sep 22, 2020 at 10:45:16AM +0200, Klaus Jensen wrote:
> > From: Klaus Jensen
> >
> > This is the next round of my patches for the nvme device.
> >
> > This includes a bit of cleanup and two new features:
> >
> > * support for scatter/gather lists
On 22/09/2020 18.16, Daniel P. Berrangé wrote:
> This thread from a little over a year ago:
>
> http://lists.wpkg.org/pipermail/sheepdog/2019-March/thread.html
>
> states that sheepdog is no longer actively developed. The only mentioned
> users are some companies who are said to have it for
On Tue, Sep 22, 2020 at 07:27:30PM +0200, Klaus Jensen wrote:
> On Sep 22 08:31, Keith Busch wrote:
> > On Tue, Sep 22, 2020 at 10:45:16AM +0200, Klaus Jensen wrote:
> > > From: Klaus Jensen
> > >
> > > This is the next round of my patches for the nvme device.
> > >
> > > This includes a bit of
22.09.2020 19:16, Daniel P. Berrangé wrote:
The sheepdog mailing list is setup to stop and queue messages from
non-subscribers, pending moderator approval. Unfortunately it seems
that the moderation queue is not actively dealt with. Even when messages
are approved, the sender is never added to
On Mon, 2020-09-21 at 18:29 +0200, Philippe Mathieu-Daudé wrote:
> Per the datasheet sections 3.1.13/3.1.14:
> "The host should not read the doorbell registers."
>
> As we don't need read access, map the doorbells with write-only
> permission. We keep a reference to this mapped address in the
>
We only access the I/O register in nvme_init().
Remove the reference in BDRVNVMeState and reduce its scope.
Signed-off-by: Philippe Mathieu-Daudé
---
block/nvme.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/block/nvme.c b/block/nvme.c
NVMeRegs only contains NvmeBar. Simplify the code by using NvmeBar
directly.
This triggers a checkpatch.pl error:
ERROR: Use of volatile is usually wrong, please add a comment
#30: FILE: block/nvme.c:691:
+volatile NvmeBar *regs;
This is a false positive as in our case we are using
Use self-explicit SCALE_MS definition instead of magic value
(missed in similar commit e4f310fe7f5).
Signed-off-by: Philippe Mathieu-Daudé
---
block/nvme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/nvme.c b/block/nvme.c
index 959569d262f..b48f6f25881 100644
---
From: Klaus Jensen
Add the symbolic command name to the pci_nvme_{io,admin}_cmd and
pci_nvme_rw trace events.
Signed-off-by: Klaus Jensen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Keith Busch
---
hw/block/nvme.h | 28
hw/block/nvme.c | 8
From: Klaus Jensen
The emulated nvme device (hw/block/nvme.c) is currently using an
internal Intel device id.
Prepare to change that by allocating a device id under the 1b36 (Red
Hat, Inc.) vendor id.
Signed-off-by: Klaus Jensen
Acked-by: Gerd Hoffmann
Reviewed-by: Maxim Levitsky
On 9/22/20 11:04 AM, Paolo Bonzini wrote:
> On 22/09/20 10:41, Philippe Mathieu-Daudé wrote:
>>> Besides looking more correct in access mode, is there any side effect
>>> of WO mapping?
>> TBH I don't have enough knowledge to answer this question.
>> I tested successfully on X86. I'm writing more
Patchew URL:
https://patchew.org/QEMU/20200922085838.230505-1-stefa...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20200922085838.230505-1-stefa...@redhat.com
Subject: [PATCH v2] qemu/atomic.h: prefix
On 21/09/20 18:23, Stefan Hajnoczi wrote:
> clang's C11 atomic_fetch_*() functions only take a C11 atomic type
> pointer argument. QEMU uses direct types (int, etc) and this causes a
> compiler error when a QEMU code calls these functions in a source file
> that also included via a system header
On 22/09/20 08:45, David Hildenbrand wrote:
>> It's certainly a good idea but it's quite verbose.
>>
>> What about using atomic__* as the prefix? It is not very common in QEMU
>> but there are some cases (and I cannot think of anything better).
>
> aqomic_*, lol :)
Actually qatomic_ would be a
On Tue, Sep 22, 2020 at 08:56:06AM +0200, Paolo Bonzini wrote:
> On 22/09/20 08:45, David Hildenbrand wrote:
> >> It's certainly a good idea but it's quite verbose.
> >>
> >> What about using atomic__* as the prefix? It is not very common in QEMU
> >> but there are some cases (and I cannot think
From: Klaus Jensen
For now, support the Data Block, Segment and Last Segment descriptor
types.
See NVM Express 1.3d, Section 4.4 ("Scatter Gather List (SGL)").
Signed-off-by: Klaus Jensen
Reviewed-by: Keith Busch
---
include/block/nvme.h | 6 +-
hw/block/nvme.c | 329
On Mon, Sep 21, 2020 at 04:29:10PM -0500, Eric Blake wrote:
> On 9/21/20 11:23 AM, Stefan Hajnoczi wrote:
Thanks for the review! Your feedback prompted me to do this more
systematically. I fixed the command-lines and published a diff of just
the manual changes I made on top of the mechanical
and assert the passing conditions in block/mirror.c. while incremental
mode was never available for drive-mirror, it makes the interface more
in line with backup block jobs.
Signed-off-by: Fabian Grünbichler
---
block/mirror.c | 28 +---
blockdev.c | 29
On Tue, 2020-09-22 at 10:38 +0200, Philippe Mathieu-Daudé wrote:
> Instead of mapping 8K of I/O + doorbells as RW during the whole
> execution, maps I/O temporarly at init, and map doorbells WO.
>
> Replace various magic values by slighly more explicit macros from
> "block/nvme.h".
>
> Since v1:
On Mon, Sep 21, 2020 at 01:56:08PM -0700, no-re...@patchew.org wrote:
> ERROR: Macros with multiple statements should be enclosed in a do - while loop
> #2968: FILE: include/qemu/atomic.h:152:
> +#define qemu_atomic_rcu_read__nocheck(ptr, valptr) \
> __atomic_load(ptr, valptr,
Use the NVMe register definitions from "block/nvme.h" which
ease a bit reviewing the code while matching the datasheet.
Signed-off-by: Philippe Mathieu-Daudé
---
block/nvme.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/block/nvme.c b/block/nvme.c
From: Klaus Jensen
Fix a typo in the sq doorbell trace event.
Signed-off-by: Klaus Jensen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Keith Busch
---
hw/block/trace-events | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/block/trace-events b/hw/block/trace-events
From: Klaus Jensen
Style fixes.
Signed-off-by: Klaus Jensen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Keith Busch
---
hw/block/nvme.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index
From: Klaus Jensen
Since the controller has only supported PRPs so far it has not been
required to check the ending address (addr + len - 1) of the CMB access
for validity since it has been guaranteed to be in range of the CMB.
This changes when the controller adds support for SGLs (next
From: John Snow
Teach mirror two new tricks for using bitmaps:
Always: no matter what, we synchronize the copy_bitmap back to the
sync_bitmap. In effect, this allows us resume a failed mirror at a later
date, since the target bdrv should be exactly in the state referenced by
the bitmap.
From: John Snow
This patch adds support for the "BITMAP" sync mode to drive-mirror and
blockdev-mirror. It adds support only for the BitmapSyncMode "never,"
because it's the simplest mode.
This mode simply uses a user-provided bitmap as an initial copy
manifest, and then does not clear any bits
based on John's in-progress work from last year, this series introduces
incremental drive-/block-dev mirror support using bitmaps with three bitmap
modes.
changes since RFC:
- rebased on current master
- squashed patches 2-4
- re-ordered patches 5/6, and moved all test code to patch 6
NOTE:
On 22/09/20 10:41, Philippe Mathieu-Daudé wrote:
>> Besides looking more correct in access mode, is there any side effect
>> of WO mapping?
> TBH I don't have enough knowledge to answer this question.
> I tested successfully on X86. I'm writing more tests.
No problem with doing this, but
On 9/22/20 10:17 AM, Stefan Hajnoczi wrote:
> On Mon, Sep 21, 2020 at 01:56:08PM -0700, no-re...@patchew.org wrote:
>> ERROR: Macros with multiple statements should be enclosed in a do - while
>> loop
>> #2968: FILE: include/qemu/atomic.h:152:
>> +#define qemu_atomic_rcu_read__nocheck(ptr,
From: Klaus Jensen
This is the next round of my patches for the nvme device.
This includes a bit of cleanup and two new features:
* support for scatter/gather lists
* multiple namespaces support through a new nvme-ns device
Finally, the series wraps up with changing the PCI vendor and
From: Klaus Jensen
This pulls block layer aio submission/completion to common functions.
For completions, additionally map an AIO error to the Unrecovered Read
and Write Fault status codes.
Signed-off-by: Klaus Jensen
---
hw/block/nvme.h | 14 +
hw/block/nvme.c | 136
From: Klaus Jensen
Move common error handling to a label.
Signed-off-by: Klaus Jensen
Reviewed-by: Keith Busch
---
hw/block/nvme.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 744ff3d86c22..a76a6464d6a1 100644
From: Klaus Jensen
There are two reasons for changing this:
1. The nvme device currently uses an internal Intel device id.
2. Since commits "nvme: fix write zeroes offset and count" and "nvme:
support multiple namespaces" the controller device no longer has
the quirks that the
From: Gollu Appalanaidu
This adds support for SGL descriptor type 0x1 (bit bucket descriptor).
See the NVM Express v1.3d specification, Section 4.4 ("Scatter Gather
List (SGL)").
Signed-off-by: Gollu Appalanaidu
Signed-off-by: Klaus Jensen
Reviewed-by: Keith Busch
---
hw/block/nvme.c | 33
From: Klaus Jensen
This adds support for multiple namespaces by introducing a new 'nvme-ns'
device model. The nvme device creates a bus named from the device name
('id'). The nvme-ns devices then connect to this and registers
themselves with the nvme device.
This changes how an nvme device is
2 years back I proposed dropping the sheepdog mailing list from the
MAINTAINERS file, but somehow the patch never got picked up:
https://lists.gnu.org/archive/html/qemu-block/2018-03/msg01048.html
So here I am with the same patch again.
I further looked at the sheepdog project though, and I'm
From: Klaus Jensen
Prepare to support inactive namespaces.
Signed-off-by: Klaus Jensen
Reviewed-by: Maxim Levitsky
Reviewed-by: Keith Busch
---
hw/block/nvme.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index
The sheepdog mailing list is setup to stop and queue messages from
non-subscribers, pending moderator approval. Unfortunately it seems
that the moderation queue is not actively dealt with. Even when messages
are approved, the sender is never added to the whitelist, so every
future mail from the
From: Klaus Jensen
Add the nvme_l2b helper and use it for converting NLB and SLBA to byte
counts and offsets.
Signed-off-by: Klaus Jensen
Reviewed-by: Keith Busch
---
hw/block/nvme.h | 6 ++
hw/block/nvme.c | 12
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git
From: Klaus Jensen
Handling DMA errors gracefully is required for the device to pass the
block/011 test ("disable PCI device while doing I/O") in the blktests
suite.
With this patch the device sets the Controller Fatal Status bit in the
CSTS register when failing to read from a submission queue
From: Klaus Jensen
The raw NLB field is a 16 bit value, so use le16_to_cpu instead of
le32_to_cpu and cast to uint32_t before incrementing the value to not
wrap around.
Signed-off-by: Klaus Jensen
Reviewed-by: Keith Busch
Reviewed-by: Philippe Mathieu-Daudé
---
hw/block/nvme.c | 4 ++--
1
From: Klaus Jensen
Some devices might want to know the return value of dma_memory_rw, so
pass it along instead of ignoring it.
There are no existing users of the return value, so this patch should be
safe.
Signed-off-by: Klaus Jensen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Michael
From: Klaus Jensen
Make the default request status NVME_SUCCESS so only error status codes
have to be set.
Signed-off-by: Klaus Jensen
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Keith Busch
---
hw/block/nvme.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
From: Prasad J Pandit
While transferring data via fdctrl_read/write_data() routines,
check that current drive does not have a null block pointer.
Avoid null pointer dereference.
-> https://ruhr-uni-bochum.sciebo.de/s/NNWP2GfwzYKeKwE?path=%2Ffdc_nullptr1
==1658854==Hint: address points to
heavily based on/practically forked off iotest 257 for bitmap backups,
but:
- no writes to filter node 'mirror-top' between completion and
finalization, as those seem to deadlock?
- no inclusion of not-yet-available full/top sync modes in combination
with bitmaps
- extra set of reference/test
On 9/22/20 3:34 AM, Alexander Bulekov wrote:
> On 200815 0020, Li Qiang wrote:
>> In 'map_page' we need to check the return value of
>> 'dma_memory_map' to ensure the we actully maped something.
>> Otherwise, we will hit an assert in 'address_space_unmap'.
>> This is because we can't find the MR
Pages are currently mapped READ/WRITE. To be able to use different
protections, add a new argument to qemu_vfio_pci_map_bar().
Signed-off-by: Philippe Mathieu-Daudé
---
include/qemu/vfio-helpers.h | 2 +-
block/nvme.c| 3 ++-
util/vfio-helpers.c | 4 ++--
3 files
Per the datasheet sections 3.1.13/3.1.14:
"The host should not read the doorbell registers."
As we don't need read access, map the doorbells with write-only
permission. We keep a reference to this mapped address in the
BDRVNVMeState structure.
Signed-off-by: Philippe Mathieu-Daudé
---
Instead of mapping 8K of I/O + doorbells as RW during the whole
execution, maps I/O temporarly at init, and map doorbells WO.
Replace various magic values by slighly more explicit macros from
"block/nvme.h".
Since v1: Fix uninitialized regs* (patchew)
Philippe Mathieu-Daudé (6):
On Tue, 2020-09-22 at 10:41 +0200, Philippe Mathieu-Daudé wrote:
> Hi Fam,
>
> +Paolo?
>
> On 9/22/20 10:18 AM, Fam Zheng wrote:
> > On Mon, 2020-09-21 at 18:29 +0200, Philippe Mathieu-Daudé wrote:
> > > Per the datasheet sections 3.1.13/3.1.14:
> > > "The host should not read the doorbell
On 22.09.20 08:27, Paolo Bonzini wrote:
> On 21/09/20 18:23, Stefan Hajnoczi wrote:
>> clang's C11 atomic_fetch_*() functions only take a C11 atomic type
>> pointer argument. QEMU uses direct types (int, etc) and this causes a
>> compiler error when a QEMU code calls these functions in a source
On 22.09.20 08:56, Paolo Bonzini wrote:
> On 22/09/20 08:45, David Hildenbrand wrote:
>>> It's certainly a good idea but it's quite verbose.
>>>
>>> What about using atomic__* as the prefix? It is not very common in QEMU
>>> but there are some cases (and I cannot think of anything better).
>>
>>
On Thu, Sep 17, 2020 at 10:44:52AM +0100, Stefan Hajnoczi wrote:
> v2:
> * Add missing undo in virtio-blk write zeroes error path [Li Qiang]
>
> Both virtio-blk and virtio-crypto use destructive iov_discard_front/back()
> operations on elem->in/out_sg. virtqueue_push() calls dma_memory_unmap()
Hi Fam,
+Paolo?
On 9/22/20 10:18 AM, Fam Zheng wrote:
> On Mon, 2020-09-21 at 18:29 +0200, Philippe Mathieu-Daudé wrote:
>> Per the datasheet sections 3.1.13/3.1.14:
>> "The host should not read the doorbell registers."
>>
>> As we don't need read access, map the doorbells with write-only
>>
Patchew URL: https://patchew.org/QEMU/20200922083821.578519-1-phi...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20200922083821.578519-1-phi...@redhat.com
Subject: [PATCH v2 0/6] block/nvme: Map
On Aug 17 08:29, Klaus Jensen wrote:
> On Jul 30 00:50, Klaus Jensen wrote:
> > On Jul 29 15:01, Andrzej Jakowski wrote:
> > > So far it was not possible to have CMB and PMR emulated on the same
> > > device, because BAR2 was used exclusively either of PMR or CMB. This
> > > patch places CMB at
In most cases, _make_test_img does not need a _filter_imgfmt on top. It
does that by itself.
(The exception is when IMGFMT has been overwritten but TEST_IMG has not.
In such cases, we do need a _filter_imgfmt on top to filter the test's
original IMGFMT from TEST_IMG.)
Signed-off-by: Max Reitz
On 22.09.20 13:14, Thomas Huth wrote:
[...]
> Could you turn this immediately into a meson test instead? See e.g.
> https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg07112.html as
> an example for how to do this.
Sure!
Max
signature.asc
Description: OpenPGP digital signature
On 9/22/20 12:37 PM, Li Qiang wrote:
> Philippe Mathieu-Daudé 于2020年9月22日周二 下午4:19写道：
>>
>> On 9/22/20 3:34 AM, Alexander Bulekov wrote:
>>> On 200815 0020, Li Qiang wrote:
In 'map_page' we need to check the return value of
'dma_memory_map' to ensure the we actully maped something.
This makes the export actually useful instead of only producing errors
whenever it is accessed.
Signed-off-by: Max Reitz
---
block/export/fuse.c | 226
1 file changed, 226 insertions(+)
diff --git a/block/export/fuse.c b/block/export/fuse.c
index
On 22/09/2020 11.01, Daniel P. Berrangé wrote:
[...]
> Does someone have a compelling reason for QEMU to keep supporting
> this driver, other than the fact that it already exists ?
>
> If not, it looks like a candidate for deprecating in QEMU with a
> view to later removing it.
I think you gave
Signed-off-by: Max Reitz
---
configure | 34 ++
meson.build | 6 ++
2 files changed, 40 insertions(+)
diff --git a/configure b/configure
index ce27eafb0a..21c31e4694 100755
--- a/configure
+++ b/configure
@@ -538,6 +538,7 @@ meson=""
ninja=""
This pretends FUSE exports are a kind of protocol. As such, they are
always tested under the format node. This is probably the best way to
test them, actually, because this will generate more I/O load and more
varied patterns.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/check |
P J P 于2020年9月22日周二 下午5:29写道：
>
> From: Prasad J Pandit
>
> While transferring data via fdctrl_read/write_data() routines,
> check that current drive does not have a null block pointer.
> Avoid null pointer dereference.
>
> ->
block-export-add type=fuse allows mounting block graph nodes via FUSE on
some existing regular file. That file should then appears like a raw
disk image, and accesses to it result in accesses to the exported BDS.
Right now, we only implement the necessary block export functions to set
it up and
These will behave more like normal files in that writes beyond the EOF
will automatically grow the export size.
Signed-off-by: Max Reitz
---
qapi/block-export.json | 6 +-
block/export/fuse.c| 12 +++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git
This allows allocating areas after the (old) EOF as part of a growing
resize, writing zeroes, and discarding.
Signed-off-by: Max Reitz
---
block/export/fuse.c | 79 +
1 file changed, 79 insertions(+)
diff --git a/block/export/fuse.c
We have good coverage of the normal I/O paths now, but what remains is a
test that tests some more special cases: Exporting an image on itself
(thus turning a formatted image into a raw one), some error cases, and
non-writable and non-growable exports.
Signed-off-by: Max Reitz
---
When most iotests want to create a test image that is named differently
from the default $TEST_IMG, they do something like this:
TEST_IMG="$TEST_IMG.base" _make_test_img $options
This works fine with the "file" protocol, but not so much for anything
else: _make_test_img tries to create an
Most Python tests are restricted to the file protocol (without
explicitly saying so), but these are the ones that would break
./check -fuse -qcow2.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/206 | 3 ++-
tests/qemu-iotests/242 | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff
Executing _make_test_img as part of a pipe will undo all variable
changes it has done. As such, this could not work with FUSE (because
we want to remember all of our exports and their qemu instances).
Replace the pipe by a temporary file in 071 and 174 (the two tests that
can run on FUSE).
Many tests (that do not support generic protocols) can run just fine
with FUSE-exported images, so allow them to. Note that this is no
attempt at being definitely complete. There are some tests that might
be modified to run on FUSE, but this patch still skips them. This patch
only tries to pick
Avoid creating images with custom filenames in $TEST_DIR, because
non-file protocols may want to keep $TEST_IMG (and all other test
images) in some other directory.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/200 | 3 +--
tests/qemu-iotests/200.out | 4 ++--
tests/qemu-iotests/229 |
qemu-img convert (without -n) can often be replaced by a combination of
_make_test_img + qemu-img convert -n. Doing so allows converting to
protocols that do not allow direct file creation, such as FUSE exports.
The only problem is that for formats other than qcow2 and qed (qcow1 at
least), this
On 22/09/20 10:58, Stefan Hajnoczi wrote:
> clang's C11 atomic_fetch_*() functions only take a C11 atomic type
> pointer argument. QEMU uses direct types (int, etc) and this causes a
> compiler error when a QEMU code calls these functions in a source file
> that also included via a system header
Philippe Mathieu-Daudé 于2020年9月22日周二 下午6:46写道：
>
> On 9/22/20 12:37 PM, Li Qiang wrote:
> > Philippe Mathieu-Daudé 于2020年9月22日周二 下午4:19写道：
> >>
> >> On 9/22/20 3:34 AM, Alexander Bulekov wrote:
> >>> On 200815 0020, Li Qiang wrote:
> In 'map_page' we need to check the return value of
>
On 04.09.2020 16:59, Vladimir Sementsov-Ogievskiy wrote:
04.09.2020 15:50, Max Reitz wrote:
On 28.08.20 18:52, Andrey Shinkevich wrote:
Limit the guest's COR operations by the base node in the backing chain
during a stream job.
I don’t understand. Shouldn’t we limit the areas where we set
Philippe Mathieu-Daudé 于2020年9月22日周二 下午4:19写道：
>
> On 9/22/20 3:34 AM, Alexander Bulekov wrote:
> > On 200815 0020, Li Qiang wrote:
> >> In 'map_page' we need to check the return value of
> >> 'dma_memory_map' to ensure the we actully maped something.
> >> Otherwise, we will hit an assert in
Based-on: <20200907182011.521007-1-kw...@redhat.com>
(“block/export: Add infrastructure and QAPI for block exports”)
(Though its patch 16 needs a s/= \_exp_nbd/= drv/ on top.)
v1: https://lists.nongnu.org/archive/html/qemu-block/2019-12/msg00451.html
Branch:
If the test environment has some other child processes running (like a
storage daemon that provides a FUSE export), then "wait" will never
finish. Use wait=yes _cleanup_qemu instead.
(We need to discard the output so there is no change to the reference
output.)
Signed-off-by: Max Reitz
---
This is a relatively new feature in libfuse (available since 3.8.0,
which was released in November 2019), so we have to let configure check
whether it is available before making use of it.
Signed-off-by: Max Reitz
---
configure | 32 +++
block/export/fuse.c | 77
Signed-off-by: Max Reitz
---
tests/qemu-iotests/check | 11 +++
tests/qemu-iotests/common.rc | 17 +
2 files changed, 28 insertions(+)
diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
index e14a1f354d..467a7cf1b7 100755
--- a/tests/qemu-iotests/check
287 creates an image in a subshell (thanks to the pipe) to see whether
that is possible with compression_type=zstd. If _make_test_img were to
modify any global state, this global state would then be lost before we
could cleanup the image.
When using FUSE as the test protocol, this global state
On 22/09/20 13:14, Thomas Huth wrote:
> On 22/09/2020 12.49, Max Reitz wrote:
>> Signed-off-by: Max Reitz
>> ---
>> configure | 34 ++
>> meson.build | 6 ++
>> 2 files changed, 40 insertions(+)
>>
>> diff --git a/configure b/configure
>> index
On 9/22/20 11:01 AM, Daniel P. Berrangé wrote:
> The sheepdog mailing list is setup to stop and queue messages from
> non-subscribers, pending moderator approval. Unfortunately it seems
> that the moderation queue is not actively dealt with. Even when messages
> are approved, the sender is never
Patchew URL:
https://patchew.org/QEMU/20200922161611.2049616-1-berra...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20200922161611.2049616-1-berra...@redhat.com
Subject: [PATCH v2 0/2] block: deprecate
The vu_client_trip() coroutine is leaked during AioContext switching. It
is also unsafe to destroy the vu_dev in panic_cb() since its callers
still access it in some cases.
Rework the lifecycle to solve these safety issues.
Signed-off-by: Stefan Hajnoczi
---
util/vhost-user-server.h
The device panic notifier callback is not used. Drop it.
Signed-off-by: Stefan Hajnoczi
---
util/vhost-user-server.h | 3 ---
block/export/vhost-user-blk-server.c | 3 +--
util/vhost-user-server.c | 6 --
3 files changed, 1 insertion(+), 11 deletions(-)
diff --git
Signed-off-by: Stefan Hajnoczi
---
util/vhost-user-server.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/vhost-user-server.c b/util/vhost-user-server.c
index 7b50a2b1fd..2cd0cf8277 100644
--- a/util/vhost-user-server.c
+++ b/util/vhost-user-server.c
@@ -407,7 +407,7
Explicitly deleting watches is not necessary since libvhost-user calls
remove_watch() during vu_deinit(). Add an assertion to check this
though.
Signed-off-by: Stefan Hajnoczi
---
util/vhost-user-server.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git
1 - 100 of 117 matches
Mail list logo
