qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 06/10] hw/arm: Select VIRTIO_BLK for virt machine


From: Fabiano Rosas
Subject: Re: [PATCH 06/10] hw/arm: Select VIRTIO_BLK for virt machine
Date: Tue, 07 Feb 2023 16:24:34 -0300

Thomas Huth <thuth@redhat.com> writes:

> On 06/02/2023 15.08, Fabiano Rosas wrote:
>> The virt machine has IF_VIRTIO as block_default_type, which causes the
>> generic code to try to create a virtio-blk-pci device pair at
>> configure_blockdev()/qemu_create_cli_devices().
>> 
>> Select VIRTIO_BLK and VIRTIO_PCI from CONFIG_ARM_VIRT to avoid errors
>> when PCI_DEVICES=n (due to e.g. --without-default-devices):
>> 
>> $ ./qemu-system-aarch64 -M virt -accel tcg -cpu max -nodefaults -cdrom 
>> foo.qcow2
>> qemu-system-aarch64: -cdrom foo.qcow2: 'virtio-blk' (alias
>> 'virtio-blk-pci') is not a valid device model name
>> 
>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> ---
>>   hw/arm/Kconfig | 1 +
>>   1 file changed, 1 insertion(+)
>> 
>> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
>> index 8dcc08b7ec..296d4f5176 100644
>> --- a/hw/arm/Kconfig
>> +++ b/hw/arm/Kconfig
>> @@ -33,6 +33,7 @@ config ARM_VIRT
>>       select ACPI_HMAT
>>       select VIRTIO_PCI
>>       select VIRTIO_NET
>> +    select VIRTIO_BLK
>
> I'm a little bit torn here ... while it makes sense for me to add VIRTIO_NET 
> so that you can run "qemu-system-aarch64 -M virt" without any additional 
> arguments, this is now about fixing additional (convenience) CLI options 
> that are optional ...
>
> I assume we need those for some qtests? What about checking for virtio-blk 
> in those tests instead?

Yes, from bios-tables-test.c.

I tried hard to avoid this kind of scenario, but ultimately it's the
-cdrom option that's broken, not the test.

That's just how the code was written. The -cdrom option can use
virtio-blk as a backend because the virt machine has IF_VIRTIO as
block_default_type. So virtio-blk is a dependency as long as -cdrom is
present in the build. Unless we change something else or guard against
it in the code somehow.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]