Michal Privoznik <mpriv...@redhat.com> writes:
> On 3/11/19 11:08 PM, Markus Armbruster wrote:
>> qemu-system-FOO's main() acts on command line arguments in its own
>> idiosyncratic order. There's not much method to its madness.
>> Whenever we find a case where one kind of command line argument needs
>> to refer to something created for another kind later, we rejigger the
>> order.
>>
>> Block devices get created long after machine properties get processed.
>> Therefore, block device machine properties can be created, but not
>> set. No such properties exist. But the next commit will create some.
>> Time to rejigger again: create block devices earlier.
>>
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>> Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com>
>> Message-Id: <20190308131445.17502-8-arm...@redhat.com>
>> Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
>> ---
>> vl.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/vl.c b/vl.c
>> index c22ca447fa..e9239d55ad 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -4274,6 +4274,13 @@ int main(int argc, char **argv, char **envp)
>> exit(0);
>> }
>> + /*
>> + * Note: we need to create block backends before
>> + * machine_set_property(), so machine properties can refer to
>> + * them.
>> + */
>> + configure_blockdev(&bdo_queue, machine_class, snapshot);
>> +
>> machine_opts = qemu_get_machine_opts();
>> qemu_opt_foreach(machine_opts, machine_set_property, current_machine,
>> &error_fatal);
>> @@ -4400,8 +4407,6 @@ int main(int argc, char **argv, char **envp)
>> ram_mig_init();
>> dirty_bitmap_mig_init();
>> - configure_blockdev(&bdo_queue, machine_class, snapshot);
>> -
>> qemu_opts_foreach(qemu_find_opts("mon"),
>> mon_init_func, NULL, &error_fatal);
>>
>>
>
> Actually, there is more problems with this. Trying to run a guest with
> persistent reservations fails after this patch is applied (git bisect
> points me to this commit). My command line is:
>
> qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 \
> -monitor stdio \
> -object pr-manager-helper,id=pr-helper0,path=/tmp/pr-helper0.sock
> -drive
> file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2
>
> \
> -device
> scsi-block,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2
>
> Honestly, I have no idea how to fix it, so I'm just raising this issue
> here. Do you want me to open a bug or something?
Let's skip the bug filing bureaucracy and go straight to debugging.
Actual and expected behavior of your reproducer, please :)
