On 06.11.2019 15:05, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2019 at 08:25:03PM -0400, John Snow wrote:
>>
>>
>> On 7/5/19 10:07 AM, Alexander Popov wrote:
>>> This assertion was introduced in the commit a718978ed58a in July 2015.
>>> It implies that the size of successful DMA transfers
On 06.11.2019 15:08, Michael S. Tsirkin wrote:
> On Wed, Nov 06, 2019 at 01:17:51PM +0300, Alexander Popov wrote:
>> On 27.07.2019 00:09, Alexander Popov wrote:
>>> On 26.07.2019 2:25:03 GMT+02:00, John Snow wrote:
Oh, this is fun.
>>> ...
I can worry about a proper fix for 4.2+.
>>>
On Wed, Nov 06, 2019 at 11:04:16AM +0100, Max Reitz wrote:
> On 06.11.19 10:24, Stefan Hajnoczi wrote:
> > On Tue, Nov 05, 2019 at 07:11:05PM +0300, Denis Plotnikov wrote:
> >> It tests proper queue size settings for all available machine types.
> >>
> >> Signed-off-by: Denis Plotnikov
> >> ---
>
On 11/6/19 6:51 AM, Max Reitz wrote:
On 17.10.19 15:01, Kevin Wolf wrote:
Add a --nbd-server option to qemu-storage-daemon to start the built-in
NBD server right away. It maps the arguments for nbd-server-start to the
command line.
Well, it doesn’t quite, because nbd-server-start takes a
On 10/18/19 9:36 AM, Vladimir Sementsov-Ogievskiy wrote:
Maybe:
if software doesn't know how to interpret the field, it may be safely ignored
unless a corresponding incompatible feature flag bit is set; however, the field
should be preserved unchanged when rewriting the image header.
+
On 11/6/19 8:58 AM, Kevin Wolf wrote:
Well, but anyway. Just as I didn’t have anything against adding QMP to
qemu-nbd, I don’t have anything against adding a new application that
kind of fulfills the same purpose. And I think introducing a new
application instead of reusing qemu-nbd that
On Mon, 2019-10-07 at 10:05 +0200, Markus Armbruster wrote:
> Maxim Levitsky writes:
>
> > On Fri, 2019-09-20 at 17:14 -0400, John Snow wrote:
> > >
> > > On 9/12/19 6:30 PM, Maxim Levitsky wrote:
> > > > This patch series is continuation of my work to add encryption
> > > > key managment to
18.10.2019 17:36, Vladimir Sementsov-Ogievskiy wrote:
> 18.10.2019 17:00, Eric Blake wrote:
>> On 10/18/19 4:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Make it more obvious how to add new fields to the version 3 header and
>>> how to interpret them.
>>>
>>> The specification is adjusted so for
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Hi,
>
> The cover letter from v1 (explaining the motivation behind this series
> and the general structure) is here:
>
> https://lists.nongnu.org/archive/html/qemu-block/2019-09/msg01323.html
>
>
> For v2, I’ve tried to address Maxim’s
On Tue, 5 Nov 2019 at 15:43, Stefan Hajnoczi wrote:
>
> The following changes since commit 36609b4fa36f0ac934874371874416f7533a5408:
>
> Merge remote-tracking branch
> 'remotes/palmer/tags/palmer-for-master-4.2-sf1' into staging (2019-11-02
> 17:59:03 +)
>
> are available in the Git
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> We do not care about the json:{} filenames here, so we can just filter
> them out and thus make the test work both with and without external data
> files.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/198 | 6 --
>
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> When using an external data file, there are no refcounts for data
> clusters. We thus have to adjust the corruption test in this patch to
> not be based around a data cluster allocation, but the L2 table
> allocation (L2 tables are still
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> The only difference is that the json:{} filename of the image looks
> different. We actually do not care about that filename in this test, we
> are only interested in (1) that there is a json:{} filename, and (2)
> whether the backing filename
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> The problem with allowing the data_file option is that you want to use a
> different data file per image used in the test. Therefore, we need to
> allow patterns like -o data_file='$TEST_IMG.data_file'.
>
> Then, we need to filter it out from
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/007 | 5 +++--
> tests/qemu-iotests/014 | 2 ++
> tests/qemu-iotests/015 | 5 +++--
> tests/qemu-iotests/026 | 5 -
> tests/qemu-iotests/029 | 5 +++--
> tests/qemu-iotests/031 | 6
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Just rm will not delete external data files. Use _rm_test_img every
> time we delete a test image.
>
> (In the process, clean up the indentation of every _cleanup() this patch
> touches.)
>
> ((Also, use quotes consistently. I am happy to
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Some tests require compat=1.1 and thus set IMGOPTS='compat=1.1'
> globally. That is not how it should be done; instead, they should
> simply set _unsupported_imgopts to compat=0.10 (compat=1.1 is the
> default anyway).
>
> This makes the
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> The image end offset as reported by qemu-img check is different when
> using an external data file; we do not care about its value here, so we
> can just filter it. Incidentally, common.rc already has _check_test_img
> for us which does
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Overwriting IMGOPTS means ignoring all user-supplied options, which is
> not what we want. Replace the current IMGOPTS use by a new BACKING_FILE
> variable.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/267 | 12
> 1
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Tests should not overwrite all user-supplied image options, but only add
> to it (which will effectively overwrite conflicting values). Accomplish
> this by passing options to _make_test_img via -o instead of $IMGOPTS.
>
> For some tests,
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> This test can run just fine with other values for refcount_bits, so we
> should filter the value from qcow2.py's dump-header. In fact, we can
> filter everything but the feature bits and header extensions, because
> that is what the test is
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/common.filter | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/tests/qemu-iotests/common.filter
> b/tests/qemu-iotests/common.filter
> index
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Print the feature fields as a set of bits so that filtering is easier.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/031.out | 36 +--
> tests/qemu-iotests/036.out | 18 +-
> tests/qemu-iotests/039.out |
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> This is useful for tests that want to whitelist fields from dump-header
> (with grep) but still print all header extensions.
>
> Signed-off-by: Max Reitz
> ---
> tests/qemu-iotests/qcow2.py | 5 +
> 1 file changed, 5 insertions(+)
>
>
On 06.11.19 15:58, Kevin Wolf wrote:
> Am 06.11.2019 um 15:37 hat Max Reitz geschrieben:
>> On 17.10.19 15:01, Kevin Wolf wrote:
>>> This series adds a new tool 'qemu-storage-daemon', which can be used to
>>> export and perform operations on block devices.
>>
>> Looks good to me.
>>
>> I remember
Am 06.11.2019 um 15:37 hat Max Reitz geschrieben:
> On 17.10.19 15:01, Kevin Wolf wrote:
> > This series adds a new tool 'qemu-storage-daemon', which can be used to
> > export and perform operations on block devices.
>
> Looks good to me.
>
> I remember a discussion at some KVM Forum a couple of
06.11.2019 16:52, Max Reitz wrote:
> On 06.11.19 14:34, Dietmar Maurer wrote:
>>
>>> On 6 November 2019 14:17 Max Reitz wrote:
>>>
>>>
>>> On 06.11.19 14:09, Dietmar Maurer wrote:
> Let me elaborate: Yes, a cluster size generally means that it is most
> “efficient” to access the
On 17.10.19 15:01, Kevin Wolf wrote:
> This series adds a new tool 'qemu-storage-daemon', which can be used to
> export and perform operations on block devices.
Looks good to me.
I remember a discussion at some KVM Forum a couple of years ago where
someone (Berto?) was asking about adding QMP to
On 17.10.19 15:02, Kevin Wolf wrote:
> This adds and parses the --monitor option, so that a QMP monitor can be
> used in the storage daemon. The monitor offers commands defined in the
> QAPI schema at storage-daemon/qapi/qapi-schema.json.
>
> Signed-off-by: Kevin Wolf
> ---
>
On 06.11.19 14:34, Dietmar Maurer wrote:
>
>> On 6 November 2019 14:17 Max Reitz wrote:
>>
>>
>> On 06.11.19 14:09, Dietmar Maurer wrote:
Let me elaborate: Yes, a cluster size generally means that it is most
“efficient” to access the storage at that size. But there’s a tradeoff.
> Let me elaborate: Yes, a cluster size generally means that it is most
> “efficient” to access the storage at that size. But there’s a tradeoff.
> At some point, reading the data takes sufficiently long that reading a
> bit of metadata doesn’t matter anymore (usually, that is).
Any network
> And if it issues a smaller request, there is no way for a guest device
> to tell it “OK, here’s your data, but note we have a whole 4 MB chunk
> around it, maybe you’d like to take that as well...?”
>
> I understand wanting to increase the backup buffer size, but I don’t
> quite understand why
> On 6 November 2019 14:17 Max Reitz wrote:
>
>
> On 06.11.19 14:09, Dietmar Maurer wrote:
> >> Let me elaborate: Yes, a cluster size generally means that it is most
> >> “efficient” to access the storage at that size. But there’s a tradeoff.
> >> At some point, reading the data takes
> The thing is, it just seems unnecessary to me to take the source cluster
> size into account in general. It seems weird that a medium only allows
> 4 MB reads, because, well, guests aren’t going to take that into account.
Maybe it is strange, but it is quite obvious that there is an optimal
On 06.11.19 14:34, Kevin Wolf wrote:
> Am 06.11.2019 um 14:11 hat Max Reitz geschrieben:
>> On 17.10.19 15:01, Kevin Wolf wrote:
>>> Add a --export option to qemu-storage-daemon to export a block node. For
>>> now, only NBD exports are implemented. Apart from the 'type' option
>>> (which is the
Am 06.11.2019 um 14:11 hat Max Reitz geschrieben:
> On 17.10.19 15:01, Kevin Wolf wrote:
> > Add a --export option to qemu-storage-daemon to export a block node. For
> > now, only NBD exports are implemented. Apart from the 'type' option
> > (which is the implied key), it maps the arguments for
On 06.11.19 14:09, Dietmar Maurer wrote:
>> Let me elaborate: Yes, a cluster size generally means that it is most
>> “efficient” to access the storage at that size. But there’s a tradeoff.
>> At some point, reading the data takes sufficiently long that reading a
>> bit of metadata doesn’t matter
On 17.10.19 15:01, Kevin Wolf wrote:
> Add a --export option to qemu-storage-daemon to export a block node. For
> now, only NBD exports are implemented. Apart from the 'type' option
> (which is the implied key), it maps the arguments for nbd-server-add to
> the command line. Example:
>
>
On 13.09.19 13:49, Max Reitz wrote:
> Another gentle ping.
And another.
Max
signature.asc
Description: OpenPGP digital signature
On 17.10.19 15:01, Kevin Wolf wrote:
> Add a --nbd-server option to qemu-storage-daemon to start the built-in
> NBD server right away. It maps the arguments for nbd-server-start to the
> command line.
Well, it doesn’t quite, because nbd-server-start takes a
SocketAddressLegacy, and this takes a
On 17.10.19 15:01, Kevin Wolf wrote:
> This adds a new binary qemu-storage-daemon that doesn't yet do more than
> some typical initialisation for tools and parsing the basic command
> options --version, --help and --trace.
>
> Signed-off-by: Kevin Wolf
> ---
> configure | 2 +-
>
On Wed, Nov 06, 2019 at 01:17:51PM +0300, Alexander Popov wrote:
> On 27.07.2019 00:09, Alexander Popov wrote:
> > On 26.07.2019 2:25:03 GMT+02:00, John Snow wrote:
> >> Oh, this is fun.
> > ...
> >> I can worry about a proper fix for 4.2+.
> >
> > Hello John,
> >
> > Thanks for your letter.
> >
On Thu, Jul 25, 2019 at 08:25:03PM -0400, John Snow wrote:
>
>
> On 7/5/19 10:07 AM, Alexander Popov wrote:
> > This assertion was introduced in the commit a718978ed58a in July 2015.
> > It implies that the size of successful DMA transfers handled in
> > ide_dma_cb() should be multiple of 512
On Mon, 4 Nov 2019 at 09:03, Max Reitz wrote:
>
> The following changes since commit 36609b4fa36f0ac934874371874416f7533a5408:
>
> Merge remote-tracking branch
> 'remotes/palmer/tags/palmer-for-master-4.2-sf1' into staging (2019-11-02
> 17:59:03 +)
>
> are available in the Git repository
On Wed, Nov 06, 2019 at 10:18:12AM +0100, Stefan Hajnoczi wrote:
> On Tue, Nov 05, 2019 at 03:56:43PM -0500, Michael S. Tsirkin wrote:
> > On Tue, Nov 05, 2019 at 07:11:02PM +0300, Denis Plotnikov wrote:
> > > @@ -47,6 +48,15 @@ static void virtio_scsi_pci_realize(VirtIOPCIProxy
> > > *vpci_dev,
On Wed, Nov 06, 2019 at 07:46:31AM +, Denis Plotnikov wrote:
>
> On 05.11.2019 23:56, Michael S. Tsirkin wrote:
> > On Tue, Nov 05, 2019 at 07:11:02PM +0300, Denis Plotnikov wrote:
> >> The patch protects from creating illegal virtio device configuration
> >> via direct virtqueue size
On 06.11.19 12:18, Dietmar Maurer wrote:
>> And if it issues a smaller request, there is no way for a guest device
>> to tell it “OK, here’s your data, but note we have a whole 4 MB chunk
>> around it, maybe you’d like to take that as well...?”
>>
>> I understand wanting to increase the backup
On 28.10.19 17:18, Max Reitz wrote:
> This fixes a bug reported on
> https://bugs.launchpad.net/qemu/+bug/185. The problem is that
> QCOW2_COMPRESSED_SECTOR_MASK is a 32-bit mask when it really needs to be
> a 64-bit mask.
>
> The launchpad report mentions only problems with qemu-img check
On 06.11.19 11:34, Wolfgang Bumiller wrote:
> On Wed, Nov 06, 2019 at 10:37:04AM +0100, Max Reitz wrote:
>> On 06.11.19 09:32, Stefan Hajnoczi wrote:
>>> On Tue, Nov 05, 2019 at 11:02:44AM +0100, Dietmar Maurer wrote:
Example: Backup from ceph disk (rbd_cache=false) to local disk:
On 06.11.19 11:18, Dietmar Maurer wrote:
>> The thing is, it just seems unnecessary to me to take the source cluster
>> size into account in general. It seems weird that a medium only allows
>> 4 MB reads, because, well, guests aren’t going to take that into account.
>
> Maybe it is strange, but
On Wed, Nov 06, 2019 at 10:37:04AM +0100, Max Reitz wrote:
> On 06.11.19 09:32, Stefan Hajnoczi wrote:
> > On Tue, Nov 05, 2019 at 11:02:44AM +0100, Dietmar Maurer wrote:
> >> Example: Backup from ceph disk (rbd_cache=false) to local disk:
> >>
> >> backup_calculate_cluster_size returns 64K
On 27.07.2019 00:09, Alexander Popov wrote:
> On 26.07.2019 2:25:03 GMT+02:00, John Snow wrote:
>> Oh, this is fun.
> ...
>> I can worry about a proper fix for 4.2+.
>
> Hello John,
>
> Thanks for your letter.
>
> I double-checked the git history and mailing list, I'm still sure
> that my fix for
On 11/5/19 9:51 PM, Michael S. Tsirkin wrote:
> On Tue, Nov 05, 2019 at 07:11:03PM +0300, Denis Plotnikov wrote:
>> seg_max has a restriction to be less or equal to virtqueue size
>> according to Virtio 1.0 specification
>>
>> Although seg_max can't be set directly, it's worth to express this
>>
On 06.11.19 10:24, Stefan Hajnoczi wrote:
> On Tue, Nov 05, 2019 at 07:11:05PM +0300, Denis Plotnikov wrote:
>> It tests proper queue size settings for all available machine types.
>>
>> Signed-off-by: Denis Plotnikov
>> ---
>> tests/qemu-iotests/267 | 154
On 06.11.19 09:32, Stefan Hajnoczi wrote:
> On Tue, Nov 05, 2019 at 11:02:44AM +0100, Dietmar Maurer wrote:
>> Example: Backup from ceph disk (rbd_cache=false) to local disk:
>>
>> backup_calculate_cluster_size returns 64K (correct for my local .raw image)
>>
>> Then the backup job starts to read
On Tue, Nov 05, 2019 at 07:11:05PM +0300, Denis Plotnikov wrote:
> It tests proper queue size settings for all available machine types.
>
> Signed-off-by: Denis Plotnikov
> ---
> tests/qemu-iotests/267 | 154 +
> tests/qemu-iotests/267.out | 1 +
>
On Wed, Nov 06, 2019 at 07:46:31AM +, Denis Plotnikov wrote:
> Could I ask why one want to the check
> whether accessing through the modern interface and how it could be checked?
BTW the VERSION_1 check I mentioned won't work in .realize() since
feature negotiation happens later at guest
On Tue, Nov 05, 2019 at 03:56:43PM -0500, Michael S. Tsirkin wrote:
> On Tue, Nov 05, 2019 at 07:11:02PM +0300, Denis Plotnikov wrote:
> > @@ -47,6 +48,15 @@ static void virtio_scsi_pci_realize(VirtIOPCIProxy
> > *vpci_dev, Error **errp)
> > VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
>
On Wed, Nov 06, 2019 at 07:46:31AM +, Denis Plotnikov wrote:
>
> On 05.11.2019 23:56, Michael S. Tsirkin wrote:
> > On Tue, Nov 05, 2019 at 07:11:02PM +0300, Denis Plotnikov wrote:
> >> The patch protects from creating illegal virtio device configuration
> >> via direct virtqueue size
On Tue, Nov 05, 2019 at 09:22:17PM +0300, Evgeny Yakovlev wrote:
> Virtio spec 1.1 (and earlier), 5.2.5.2 Driver Requirements: Device
> Initialization:
>
> "Devices SHOULD always offer VIRTIO_BLK_F_FLUSH, and MUST offer it if
> they offer VIRTIO_BLK_F_CONFIG_WCE"
>
> Currently F_CONFIG_WCE and
On Tue, Nov 05, 2019 at 11:02:44AM +0100, Dietmar Maurer wrote:
> Example: Backup from ceph disk (rbd_cache=false) to local disk:
>
> backup_calculate_cluster_size returns 64K (correct for my local .raw image)
>
> Then the backup job starts to read 64K blocks from ceph.
>
> But ceph always
61 matches
Mail list logo
