qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Alberto Garcia <berto@igalia.com>
Cc: qemu-devel@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
	qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/6] Acquire the AioContext during _realize()
Date: Wed, 16 Jan 2019 13:54:44 +0000	[thread overview]
Message-ID: <20190116135444.GA16898@stefanha-x1.localdomain> (raw)
In-Reply-To: <cover.1547475602.git.berto@igalia.com>

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

On Mon, Jan 14, 2019 at 04:23:58PM +0200, Alberto Garcia wrote:
> 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). The other
> devices don't currently support iothreads so there's no crashes.
> 
> Berto

My assumption has been that drives are in the main loop AioContext until
the device model (e.g. virtio-blk) decides to move them into the
IOThread configured by the user.

(And when the VM is stopped or the device is removed, the drive is moved
back into the main loop AioContext by the device.)

The x-blockdev-set-iothread command is for low-level tests so I don't
expect users to invoke it.  So I'm not sure which real-world scenario is
being tested here?

This patch series makes virtio-blk and virtio-scsi more robust, although
I haven't checked what happens if the drive is attached to a different
IOThread than the device - will the switchover work?

What I'm unclear about is why fdc, ide, usb-msd, and nvme should worry
about IOThreads/AioContext in .realize() since they don't support it in
their data path.  What happens when you submit I/O requests to devices
configured like this?  I guess they would crash or hit assertion
failures since they invoke blk_aio_*() APIs from outside the appropriate
AioContext.

Maybe fdc and friends should forbid this scenario:

  /* Fail if @blk is attached to an IOThread */
  static bool blk_check_main_aio_context(BlockBackend *blk, Error **errp) {
      if (blk_get_aio_context(blk) != qemu_get_aio_context()) {
          error_setg(errp, "Device does not support iothreads");
          return false;
      }
      return true;
  }

  ...in a realize() function...
  if (!blk_check_main_aio_context(blk, errp)) {
      return;
  }

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2019-01-16 13:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14 14:23 [Qemu-devel] [PATCH v2 0/6] Acquire the AioContext during _realize() Alberto Garcia
2019-01-14 14:23 ` [Qemu-devel] [PATCH v2 1/6] block: Acquire the AioContext in virtio_blk_device_realize() Alberto Garcia
2019-01-14 14:24 ` [Qemu-devel] [PATCH v2 2/6] block: Acquire the AioContext in scsi_*_realize() Alberto Garcia
2019-01-14 14:24 ` [Qemu-devel] [PATCH v2 3/6] block: Acquire the AioContext in floppy_drive_realize() Alberto Garcia
2019-01-14 14:24 ` [Qemu-devel] [PATCH v2 4/6] block: Acquire the AioContext in nvme_realize() Alberto Garcia
2019-01-14 14:24 ` [Qemu-devel] [PATCH v2 5/6] block: Acquire the AioContext in ide_dev_initfn() Alberto Garcia
2019-01-14 14:24 ` [Qemu-devel] [PATCH v2 6/6] block: Acquire the AioContext in usb_msd_storage_realize() Alberto Garcia
2019-01-16 13:54 ` Stefan Hajnoczi [this message]
2019-01-17 13:24   ` [Qemu-devel] [PATCH v2 0/6] Acquire the AioContext during _realize() Alberto Garcia
2019-01-18  9:56     ` Stefan Hajnoczi
2019-01-18 10:14       ` Kevin Wolf
2019-01-22 13:56         ` Alberto Garcia
2019-01-18 10:35 ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190116135444.GA16898@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=berto@igalia.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).