Skip to content

run_qemu.sh: replace SATA -drive with -device virtio-blk #210

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

ikitayama
Copy link
Collaborator

This is a retry of #201

With the proposed V13 of the CXL series for the QEMU upstream applied, qemu-system-aarch64
fails to boot with the legacy -drive option alone to set root.img:

qemu-system-aarch64: -drive file=root.img,format=raw,media=disk: PCI: Only PCI/PCIe bridges can be plugged into pxb-cxl

Jonathan explains this is due to on arm64 -drive is virtoi-blk by default and we need to set a bus via the -device option. Do it as Jonathan suggested in:

https://lore.kernel.org/all/[email protected]/

without losing backward compatibility.

…, qemu-system-aarch64

fails to boot with the legacy -drive option alone to set root.img:

qemu-system-aarch64: -drive file=root.img,format=raw,media=disk: PCI: Only PCI/PCIe bridges can be plugged into pxb-cxl

Jonathan explains this is due to on arm64 -drive is virtoi-blk by default and we need
to set a bus via the -device option. Do it as Jonathan suggested in:

https://lore.kernel.org/all/[email protected]/

without losing backward compatibility.
@ikitayama ikitayama requested a review from stellarhopper as a code owner May 21, 2025 04:57
Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested this and it works and seems even a bit faster but...

If we drop the unstable -drive shortcut, then let's really drop it and replace it with -blockdev + -device as recommended by https://www.qemu.org/docs/master/system/qemu-manpage.html#hxtool-1

I mean let's not replace -drive by ( -blockdev + ... -drive!? )

I just tested this below and it works for me too:

qcmd+=("-blockdev" "driver=file,node-name=maindisk,filename=$_arg_rootfs")
qcmd+=("-device" "virtio-blk,bus=pcie.0,drive=maindisk")

https://www.qemu.org/docs/master/system/qemu-manpage.html#hxtool-1

The QEMU block device handling options have a long history and have gone through several iterations as the feature set and complexity of the block layer have grown. Many online guides to QEMU often reference older and deprecated options, which can lead to confusion.

The most explicit way to describe disks is to use a combination of -device to specify the hardware device and -blockdev to describe the backend. The device defines what the guest sees and the backend describes how QEMU handles the data. It is the only guaranteed stable interface for describing block devices and as such is recommended for management tools and scripting.

The -drive option combines the device and backend into a single command line option which is a more human friendly. There is however no interface stability guarantee although some older board models still need updating to work with the modern blockdev forms.

@marc-hb
Copy link
Collaborator

marc-hb commented May 21, 2025

Please limit your commit subject to less than 80 lines which is the standard across projects including the linux kernel but not just

https://www.kernel.org/doc/html/v6.15-rc7/process/submitting-patches.html#the-canonical-patch-format
https://www.qemu.org/docs/master/devel/submitting-a-patch.html#write-a-meaningful-commit-message
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure

[run_qemu]$ ../kernel/scripts/checkpatch.pl --no-tree -g HEAD
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)

@marc-hb
Copy link
Collaborator

marc-hb commented May 21, 2025

Also, don't describe the problem in the subject, problems can rarely be described in just 1 line. So, the commit subject must focus on the change made, example: run_qemu.sh: replace SATA -drive with -device virtio-blk

The rest of the commit message has unlimited space to describe the problem, rationale, solution, etc.

@ikitayama
Copy link
Collaborator Author

All noted and I give my Tested-by: tag

Tested-by: Itaru Kitayama <[email protected]>

@marc-hb
Copy link
Collaborator

marc-hb commented May 21, 2025

You cannot give a Tested-by: tag to yourself, it's implied :-)

I realize I suggested a lot of changes relative to the small size of this patch but this is still your PR and your work, can you please force-push a revised version? Add my Tested-by tag :-)

There is a "co-developed-by" tag if you think it is important. For a change that small I do not mind.
https://www.kernel.org/doc/html/v6.15-rc7/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

Note to self: after this is merged, add cache.no-flush=on to -blockdev when [[ $_arg_rw == "off" ]. On my systems, it makes FIO writes 5 times faster (except when root.img is on tmpfs, then it makes no difference)

@jic23
Copy link

jic23 commented May 21, 2025

Nice work. I was coming here to suggest that change only to find @ikitayama already proposed it and it was already improved on :)

@ikitayama
Copy link
Collaborator Author

You cannot give a Tested-by: tag to yourself, it's implied :-)

I realize I suggested a lot of changes relative to the small size of this patch but this is still your PR and your work, can you please force-push a revised version? Add my Tested-by tag :-)

There is a "co-developed-by" tag if you think it is important. For a change that small I do not mind. https://www.kernel.org/doc/html/v6.15-rc7/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

Note to self: after this is merged, add cache.no-flush=on to -blockdev when [[ $_arg_rw == "off" ]. On my systems, it makes FIO writes 5 times faster (except when root.img is on tmpfs, then it makes no difference)

@marc-hb The options you proposed look promising (I did not know it at all) and the rational sounds, while you're at it, would you go ahead and extend this PR or make a new PR as I don't have time today and tomorrow much?

@marc-hb
Copy link
Collaborator

marc-hb commented May 21, 2025

I don't think anyone needs this besides you, so there is no rush to get it merged. We can wait until you have the time to get back to it.

@marc-hb
Copy link
Collaborator

marc-hb commented Jun 5, 2025

@ikitayama any time to resume this?

(I can add the cache.no-flush=on later)

@ikitayama ikitayama changed the title Use both the -drive and -device options to set root.img run_qemu.sh: replace SATA -drive with -device virtio-blk Jun 10, 2025
@ikitayama ikitayama closed this Jun 10, 2025
@ikitayama ikitayama deleted the qcmd-update branch June 10, 2025 04:55
@ikitayama
Copy link
Collaborator Author

@marc-hb sorry about the long delay. Would you review your proposed change to drop the -drive option from the script?

marc-hb added a commit to marc-hb/run_qemu that referenced this pull request Jun 10, 2025
This is a retry of pmem#210.

According to Itaru Kitayam, this fixes the following error:

  qemu-system-aarch64: -drive file=root.img,format=raw,media=disk: PCI:
    Only PCI/PCIe bridges can be plugged into pxb-cxl

Jonathan explains this is due to on arm64 -drive is virtoi-blk by
default and we need to set a bus via the -device option. Do it as
Jonathan suggested in:

https://lore.kernel.org/linux-cxl/[email protected]/

From https://www.qemu.org/docs/master/system/qemu-manpage.html#hxtool-1

  The QEMU block device handling options have a long history and have gone
  through several iterations as the feature set and complexity of the
  block layer have grown. Many online guides to QEMU often reference older
  and deprecated options, which can lead to confusion.

  The most explicit way to describe disks is to use a combination of
  -device to specify the hardware device and -blockdev to describe the
  backend. The device defines what the guest sees and the backend
  describes how QEMU handles the data. It is the only guaranteed stable
  interface for describing block devices and as such is recommended for
  management tools and scripting.

  The -drive option combines the device and backend into a single command
  line option which is a more human friendly. There is however no
  interface stability guarantee although some older board models still
  need updating to work with the modern blockdev forms.

Co-developed-by: Jonathan Cameron <[email protected]>
Co-developed-by: Itaru Kitayama <[email protected]>
Tested-by: Itaru Kitayama <[email protected]>
Signed-off-by: Marc Herbert <[email protected]>
marc-hb added a commit to marc-hb/run_qemu that referenced this pull request Jun 10, 2025
According to Itaru Kitayam in pmem#210, this fixes the following error:

```
  qemu-system-aarch64: -drive file=root.img,format=raw,media=disk: PCI:
    Only PCI/PCIe bridges can be plugged into pxb-cxl
```

> Jonathan explains this is due to on arm64 -drive is virtoi-blk by
> default and we need to set a bus via the -device option. Do it as
> Jonathan suggested in:
>
> https://lore.kernel.org/linux-cxl/[email protected]/

From https://www.qemu.org/docs/master/system/qemu-manpage.html#hxtool-1

  The QEMU block device handling options have a long history and have gone
  through several iterations as the feature set and complexity of the
  block layer have grown. Many online guides to QEMU often reference older
  and deprecated options, which can lead to confusion.

  The most explicit way to describe disks is to use a combination of
  -device to specify the hardware device and -blockdev to describe the
  backend. The device defines what the guest sees and the backend
  describes how QEMU handles the data. It is the only guaranteed stable
  interface for describing block devices and as such is recommended for
  management tools and scripting.

  The -drive option combines the device and backend into a single command
  line option which is a more human friendly. There is however no
  interface stability guarantee although some older board models still
  need updating to work with the modern blockdev forms.

Co-developed-by: Jonathan Cameron <[email protected]>
Co-developed-by: Itaru Kitayama <[email protected]>
Tested-by: Itaru Kitayama <[email protected]>
Signed-off-by: Marc Herbert <[email protected]>
marc-hb added a commit to marc-hb/run_qemu that referenced this pull request Jun 10, 2025
According to Itaru Kitayama in pmem#210, this fixes the following error:

```
  qemu-system-aarch64: -drive file=root.img,format=raw,media=disk: PCI:
    Only PCI/PCIe bridges can be plugged into pxb-cxl
```

> Jonathan explains this is due to on arm64 -drive is virtoi-blk by
> default and we need to set a bus via the -device option. Do it as
> Jonathan suggested in:
>
> https://lore.kernel.org/linux-cxl/[email protected]/

From https://www.qemu.org/docs/master/system/qemu-manpage.html#hxtool-1

  The QEMU block device handling options have a long history and have gone
  through several iterations as the feature set and complexity of the
  block layer have grown. Many online guides to QEMU often reference older
  and deprecated options, which can lead to confusion.

  The most explicit way to describe disks is to use a combination of
  -device to specify the hardware device and -blockdev to describe the
  backend. The device defines what the guest sees and the backend
  describes how QEMU handles the data. It is the only guaranteed stable
  interface for describing block devices and as such is recommended for
  management tools and scripting.

  The -drive option combines the device and backend into a single command
  line option which is a more human friendly. There is however no
  interface stability guarantee although some older board models still
  need updating to work with the modern blockdev forms.

Co-developed-by: Jonathan Cameron <[email protected]>
Co-developed-by: Itaru Kitayama <[email protected]>
Tested-by: Itaru Kitayama <[email protected]>
Signed-off-by: Marc Herbert <[email protected]>
@marc-hb
Copy link
Collaborator

marc-hb commented Jun 11, 2025

Re-submitted in #211, @ikitayama , @jic23 please review and test. It's still only 2 lines long.

marc-hb added a commit that referenced this pull request Jun 11, 2025
According to Itaru Kitayama in #210, this fixes the following error:

```
  qemu-system-aarch64: -drive file=root.img,format=raw,media=disk: PCI:
    Only PCI/PCIe bridges can be plugged into pxb-cxl
```

> Jonathan explains this is due to on arm64 -drive is virtoi-blk by
> default and we need to set a bus via the -device option. Do it as
> Jonathan suggested in:
>
> https://lore.kernel.org/linux-cxl/[email protected]/

From https://www.qemu.org/docs/master/system/qemu-manpage.html#hxtool-1

  The QEMU block device handling options have a long history and have gone
  through several iterations as the feature set and complexity of the
  block layer have grown. Many online guides to QEMU often reference older
  and deprecated options, which can lead to confusion.

  The most explicit way to describe disks is to use a combination of
  -device to specify the hardware device and -blockdev to describe the
  backend. The device defines what the guest sees and the backend
  describes how QEMU handles the data. It is the only guaranteed stable
  interface for describing block devices and as such is recommended for
  management tools and scripting.

  The -drive option combines the device and backend into a single command
  line option which is a more human friendly. There is however no
  interface stability guarantee although some older board models still
  need updating to work with the modern blockdev forms.

Co-developed-by: Jonathan Cameron <[email protected]>
Co-developed-by: Itaru Kitayama <[email protected]>
Tested-by: Itaru Kitayama <[email protected]>
Signed-off-by: Marc Herbert <[email protected]>
@marc-hb
Copy link
Collaborator

marc-hb commented Jun 14, 2025

(I can add the cache.no-flush=on later)

I experimented with this and --name=testfio --size=10M --rw=randwrite --runtime=30 --time_based --eta-newline=2 --ioengine=sync and other variations and I could not spot any significant difference. Let's forget it for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants