10.01.2019 23:51, Eric Blake wrote:
> On 1/10/19 7:20 AM, Vladimir Sementsov-Ogievskiy wrote:
>> drv_co_block_status digs bs->file for additional, more accurate search
>> for hole inside region, reported as DATA by bs since 5daa74a6ebc.
>
> s/region, reported/regions reported/
>
>>
>> This accura
Leonid Bloch writes:
> On 1/10/19 2:51 PM, wrote:
>> Leonid Bloch writes:
>>
>>> Hi,
>>>
>>> On 1/8/19 2:20 PM, Kevin Wolf wrote:
Am 03.01.2019 um 22:33 hat Leonid Bloch geschrieben:
> The lookup table for power-of-two sizes is now auto-generated during the
> build, and not hard-c
On Thu, 2019-01-10 at 14:57 +0100, Peter Lieven wrote:
> Am 18.12.18 um 15:45 schrieb Peter Lieven:
> > Am 18.12.18 um 14:15 schrieb Vadim Rozenfeld:
> > > Peter, I must be missing something here, but what exactly the
> > > problem
> > > is?
> >
> > The issue is that I see concurrent read requests
On 1/4/19 5:45 PM, Eric Blake wrote:
> On 12/18/18 7:46 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 15.12.2018 16:53, Eric Blake wrote:
>>> The next commit will add an EXAMPLES section to qemu-nbd.8;
>>> for that to work, we need to recognize EXAMPLES in texi2pod,
>>> and we need to make all man pag
This patchset contains small fix.
Change since v1:
1. drop the patch of checking return value of msix_init_exclusive_bar
2. return when nvme's num_queues configuration is 0
Li Qiang (3):
nvme: use TYPE_NVME instead of constant string
nvme: ensure the num_queues is not zero
nvme: use pci_d
There is no need to make another reference.
Signed-off-by: Li Qiang
Reviewed-by: Max Reitz
---
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 0ded74fa9a..0a1da749fc 100644
--- a/hw/block/nvme.c
+++ b/hw/block/n
Signed-off-by: Li Qiang
Reviewed-by: Max Reitz
---
hw/block/nvme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 7c8c63e8f5..f206391e8e 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1381,7 +1381,7 @@ static void nvme_instance
When it is zero, it causes segv. Backtrack:
Thread 5 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc6c17700 (LWP 51808)]
0x55acbd90 in nvme_start_ctrl (n=0x624c8100) at hw/block/nvme.c:820
warning: Source file is more recent than executable.
8
On 1/10/19 9:11 AM, Nikolay Shirokovskiy wrote:
>>> The experimental command included an optional 'bitmap-export-name'
>>> field for remapping the name exposed over NBD to be different from
>>> the bitmap name stored on disk.
>>
>>
>> Nikolay, do you have comments on this?
>>
>>
>>However, my
On 1/10/19 7:20 AM, Vladimir Sementsov-Ogievskiy wrote:
> drv_co_block_status digs bs->file for additional, more accurate search
> for hole inside region, reported as DATA by bs since 5daa74a6ebc.
s/region, reported/regions reported/
>
> This accuracy is not free: assume we have qcow2 disk. Actu
On 1/10/19 2:21 PM, Eric Blake wrote:
> On 1/10/19 1:26 PM, Eric Blake wrote:
>> On 1/10/19 1:18 PM, Eric Blake wrote:
>>> Patches speak louder than words. This is my counter-proposal to
>>> Leonid's thread on how best to respresent the S_*iB macros in units.h,
>>> where my proposal is that we don
On 1/10/19 1:26 PM, Eric Blake wrote:
> On 1/10/19 1:18 PM, Eric Blake wrote:
>> Patches speak louder than words. This is my counter-proposal to
>> Leonid's thread on how best to respresent the S_*iB macros in units.h,
>> where my proposal is that we don't need them at all. (hence my subject
>> li
On 1/10/19 1:18 PM, Eric Blake wrote:
> This reverts commit 3dd5b8f4718c6ca1eadb16dd67a8cad76455ddb0.
>
> Now that we can express QemuOpts values as an integer, we don't have
> to be careful about how we spell our macro.
Signed-off-by: Eric Blake
> ---
> block/vdi.c | 4 ++--
> 1 file changed,
On 1/10/19 7:33 AM, Eric Blake wrote:
>> Eric - thanks for the comment about 'local' - I will get rid of it if we
>> decide to include this patch.
>
> I'm still not convinced we need it. I would much rather see a patch
> that makes QemuOpt accept default integer values as integers rather than
>
On 1/10/19 1:18 PM, Eric Blake wrote:
> Patches speak louder than words. This is my counter-proposal to
> Leonid's thread on how best to respresent the S_*iB macros in units.h,
> where my proposal is that we don't need them at all. (hence my subject
> line, even though it is completely unrelated t
This reverts commit 540b8492618ebbe98e7462bd7d31361b8cb10a05.
Now that QemuOpts can accept default values as integers, there
are no more clients of the S_*iB macros, and no longer a reason
to have a list of macros that contain a specific spelling of
special values merely for the sake of stringify(
This reverts commit 1240ac558d348f6c7a5752b1a57c1da58e4efe3e.
The table itself is about to be reverted, now that it has no clients.
Signed-off-by: Eric Blake
---
include/qemu/units.h | 18 --
1 file changed, 18 deletions(-)
diff --git a/include/qemu/units.h b/include/qemu/units
Set the framework up for declaring integer options with an integer
default, instead of our current insane approach of requiring the
default value to be given as a string (which then has to be reparsed
at every use that wants a number). git grep '[^.]def_value_str' says
that we have done a good job
Instead of defining an integer to a default string value (where we
have to be careful how we spelled the integer because of the use of
stringify), populate a default integer value instead.
Drop a useless stringify(0); a missing default is just as easy to
interpret as 0 as an explicit string 0.
Si
Now that QemuOpts can accept true integer defaults, we no longer
have to be careful about the spelling of our default macros because
we are no longer applying stringify() to any of the macros.
Although it is slightly more verbose to call out an integer times
a scale, it avoids the need to have a li
This reverts commit 3dd5b8f4718c6ca1eadb16dd67a8cad76455ddb0.
Now that we can express QemuOpts values as an integer, we don't have
to be careful about how we spell our macro.
---
block/vdi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/vdi.c b/block/vdi.c
index 65
Patches speak louder than words. This is my counter-proposal to
Leonid's thread on how best to respresent the S_*iB macros in units.h,
where my proposal is that we don't need them at all. (hence my subject
line, even though it is completely unrelated to the series)
True, my diffstat is even bigge
Leonid Bloch writes:
> On 1/10/19 2:40 PM, Markus Armbruster wrote:
>> Leonid Bloch writes:
>>
>>> Hi,
>>>
>>> On 1/8/19 11:31 AM, Markus Armbruster wrote:
I'd leave it hard-coded. Replacing a few trivial defines by an arguably
less trivial script doesn't feel like an improvement. I
On 1/10/19 2:51 PM, wrote:
> Leonid Bloch writes:
>
>> Hi,
>>
>> On 1/8/19 2:20 PM, Kevin Wolf wrote:
>>> Am 03.01.2019 um 22:33 hat Leonid Bloch geschrieben:
The lookup table for power-of-two sizes is now auto-generated during the
build, and not hard-coded into the units.h file.
On 1/10/19 2:40 PM, Markus Armbruster wrote:
> Leonid Bloch writes:
>
>> Hi,
>>
>> On 1/8/19 11:31 AM, Markus Armbruster wrote:
>>> I'd leave it hard-coded. Replacing a few trivial defines by an arguably
>>> less trivial script doesn't feel like an improvement. In this case, it
>>> doesn't even
On Wed, 9 Jan 2019 at 13:23, Laurent Vivier wrote:
>
> The following changes since commit 147923b1a901a0370f83a0f4c58ec1baffef22f0:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/usb-20190108-pull-request' into staging (2019-01-08
> 16:07:32 +)
>
> are available in the Git reposit
ping
14.12.2018 16:42, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> These series are derived from "[PATCH v3 0/8] qcow2 check improvements"
> (https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02284.html)
>
> Some patches are new, some patches are not included and are postponed to
>
On 10.01.2019 15:02, Vladimir Sementsov-Ogievskiy wrote:
> cc Nikolay
>
> 10.01.2019 10:13, Eric Blake wrote:
>> With the experimental x-nbd-server-add-bitmap command, there was
>> a window of time where an NBD client could see the export but not
>> the associated dirty bitmap, which can cause a
10.01.2019 17:44, Eric Blake wrote:
> On 1/10/19 4:40 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 10.01.2019 10:13, Eric Blake wrote:
>>> The existing NBD code had a weird split where nbd_export_new()
>>> created an export but did not add it to the list of exported
>>> names until a later nbd_export
Signed-off-by: Alberto Garcia
---
hw/ide/qdev.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 573b022e1e..f355f2a352 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -160,6 +160,7 @@ static void ide_dev_initfn(IDEDevice
Signed-off-by: Alberto Garcia
---
hw/usb/dev-storage.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/usb/dev-storage.c b/hw/usb/dev-storage.c
index cd5551d94f..fa6e552f0f 100644
--- a/hw/usb/dev-storage.c
+++ b/hw/usb/dev-storage.c
@@ -593,13 +593,18 @@ static void usb_msd_storage_r
This fixes the following crash:
{ "execute": "blockdev-add",
"arguments": {"driver": "null-co", "node-name": "hd0"}}
{ "execute": "object-add",
"arguments": {"qom-type": "iothread", "id": "iothread0"}}
{ "execute": "x-blockdev-set-iothread",
"arguments": {"node-name": "hd0", "iothread": "iot
Signed-off-by: Alberto Garcia
---
hw/block/nvme.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 7c8c63e8f5..72e94aff86 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1203,6 +1203,7 @@ static void nvme_realize(PCI
As discussed yesterday, this series acquires the AioContext in the
_realize() functions of several devices before making use of their
block backends. This fixes at least a couple of crashes (in virtio-blk
and scsi).
Berto
Alberto Garcia (6):
block: Acquire the AioContext in virtio_blk_device_re
This fixes the following crash:
{ "execute": "blockdev-add",
"arguments": {"driver": "null-co", "node-name": "hd0"}}
{ "execute": "object-add",
"arguments": {"qom-type": "iothread", "id": "iothread0"}}
{ "execute": "x-blockdev-set-iothread",
"arguments": {"node-name": "hd0", "iothread": "iot
Signed-off-by: Alberto Garcia
---
hw/block/fdc.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 6f19f127a5..d9bc80de83 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -512,6 +512,7 @@ static void floppy_drive_realize(
10.01.2019 17:38, Eric Blake wrote:
> On 1/10/19 4:27 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 10.01.2019 10:13, Eric Blake wrote:
>>> Our initial implementation of x-nbd-server-add-bitmap put
>>> in a restriction because of incremental backups: in that
>>> usage, we are exporting one qcow2 file
On 1/10/19 6:25 AM, Vladimir Sementsov-Ogievskiy wrote:
> 10.01.2019 10:13, Eric Blake wrote:
>> We only have one caller that wants to export a bitmap name,
>> which it does right after creation of the export. But there is
>> still a brief window of time where an NBD client could see the
>> export
On 1/10/19 4:40 AM, Vladimir Sementsov-Ogievskiy wrote:
> 10.01.2019 10:13, Eric Blake wrote:
>> The existing NBD code had a weird split where nbd_export_new()
>> created an export but did not add it to the list of exported
>> names until a later nbd_export_set_name() came along and grabbed
>> a se
On 1/10/19 4:27 AM, Vladimir Sementsov-Ogievskiy wrote:
> 10.01.2019 10:13, Eric Blake wrote:
>> Our initial implementation of x-nbd-server-add-bitmap put
>> in a restriction because of incremental backups: in that
>> usage, we are exporting one qcow2 file (the temporary overlay
>> target of a bloc
Am 18.12.18 um 15:45 schrieb Peter Lieven:
Am 18.12.18 um 14:15 schrieb Vadim Rozenfeld:
Peter, I must be missing something here, but what exactly the problem
is?
The issue is that I see concurrent read requests coming in from Windows Guest
with vioscsi as driver that
have the same buffer ad
On 1/10/19 3:42 AM, Leonid Bloch wrote:
> If you've noticed, the original script was in AWK. But to be as generic
> as possible, I didn't write the generation script in AWK because even
> AWK is not guaranteed to be installed on the build system. The only
> interpreted language that is guarante
drv_co_block_status digs bs->file for additional, more accurate search
for hole inside region, reported as DATA by bs since 5daa74a6ebc.
This accuracy is not free: assume we have qcow2 disk. Actually, qcow2
knows, where are holes and where is data. But every block_status
request calls lseek additi
On Tue 08 Jan 2019 01:20:21 PM CET, Kevin Wolf wrote:
> During a downstream review, Max found a problem with the table that we
> could fix while we're touching it:
>
> Upstream: All >= S_2GiB are not valid ints. (qemu assumes that
> sizeof(int) == 4, right?) So S_2GiB should be 2147483648
Leonid Bloch writes:
> Hi,
>
> On 1/8/19 2:20 PM, Kevin Wolf wrote:
>> Am 03.01.2019 um 22:33 hat Leonid Bloch geschrieben:
>>> The lookup table for power-of-two sizes is now auto-generated during the
>>> build, and not hard-coded into the units.h file.
>>>
>>> This partially reverts commit 540b8
Leonid Bloch writes:
> Hi,
>
> On 1/8/19 11:31 AM, Markus Armbruster wrote:
>> I'd leave it hard-coded. Replacing a few trivial defines by an arguably
>> less trivial script doesn't feel like an improvement. In this case, it
>> doesn't even save lines.
>
> As I've said, I'm fine with that. The
10.01.2019 10:13, Eric Blake wrote:
> We only have one caller that wants to export a bitmap name,
> which it does right after creation of the export. But there is
> still a brief window of time where an NBD client could see the
> export but not the dirty bitmap, which a robust client would
> have t
10.01.2019 10:13, Eric Blake wrote:
> Now that nbd-server-add can do the same functionality, we no
> longer need the experimental separate command.
>
> Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
cc Nikolay
10.01.2019 10:13, Eric Blake wrote:
> With the experimental x-nbd-server-add-bitmap command, there was
> a window of time where an NBD client could see the export but not
> the associated dirty bitmap, which can cause a client that planned
> on using the dirty bitmap to be forced to tre
10.01.2019 10:13, Eric Blake wrote:
> With the experimental x-nbd-server-add-bitmap command, there was
> a window of time where an NBD client could see the export but not
> the associated dirty bitmap, which can cause a client that planned
> on using the dirty bitmap to be forced to treat the entir
10.01.2019 10:13, Eric Blake wrote:
> The existing NBD code had a weird split where nbd_export_new()
> created an export but did not add it to the list of exported
> names until a later nbd_export_set_name() came along and grabbed
> a second reference on the object; later, nbd_export_close()
> drop
10.01.2019 10:13, Eric Blake wrote:
> Our initial implementation of x-nbd-server-add-bitmap put
> in a restriction because of incremental backups: in that
> usage, we are exporting one qcow2 file (the temporary overlay
> target of a blockdev-backup sync:none job) and a dirty bitmap
> owned by a sec
Hi,
On 1/8/19 2:20 PM, Kevin Wolf wrote:
> Am 03.01.2019 um 22:33 hat Leonid Bloch geschrieben:
>> The lookup table for power-of-two sizes is now auto-generated during the
>> build, and not hard-coded into the units.h file.
>>
>> This partially reverts commit 540b8492618eb.
>>
>> Signed-off-by: Le
Hi,
On 1/8/19 11:31 AM, Markus Armbruster wrote:
> I'd leave it hard-coded. Replacing a few trivial defines by an arguably
> less trivial script doesn't feel like an improvement. In this case, it
> doesn't even save lines.
As I've said, I'm fine with that. The autogeneration sounds the right
t
54 matches
Mail list logo
