From: Eric Blake <eblake@redhat.com>
To: Chris Friesen <chris.friesen@windriver.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] question about block size and virtual disks
Date: Thu, 20 Apr 2017 16:21:16 -0500 [thread overview]
Message-ID: <a09762ce-092f-6fb1-6cc3-08a94a3c3dd1@redhat.com> (raw)
In-Reply-To: <58F92229.1080402@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
On 04/20/2017 04:03 PM, Chris Friesen wrote:
> Hi,
>
> Suppose the host has a physical disk that only supports 4KB access, with
> no 512B fallback.
>
> If we boot a guest with "cache=none", does the guest need to be able to
> handle disks with 4KB blocks or is qemu able to handle guests trying to
> access the disk with 512B granularity?
qemu should be able to handle the fallback automatically (that is, the
block layer is smart enough to honor bs->bl.request_alignment=4096 such
that it will never submit a request smaller than 4096 to the underlying
host storage, regardless of what size request the guest uses).
In fact, the blkdebug driver can be used to test this setup on top of
any real driver constraints, so we have some pretty good assurance that
our minimum-size code works even when tested on a platform that still
has 512B granularity.
>
> Also, does the 4KB block size get "passed-through" to the guest somehow
> so that the guest knows it needs to use 4KB blocks, or does that need to
> be explicitly specified via virtio-blk-pci.logical_block_size and/or
> virtio-blk-pci.physical_block_size parameters? (Assuming I'm using
> virtio-blk-pci.)
Again, qemu should be passing the advertisement of host properties down
to the guest insofar as possible (so a good guest will see that the
hardware is 4k only and will not try to make 512-byte requests), but at
the same time, qemu should handle guests that are so old that they are
blissfully unaware of the hardware advertisements and send 512-byte
requests anyway. Of course, such guests are penalized with
read-modify-write delays when submitting 512-byte IO. But explicitly
stating available parameters is always the wisest course of action, if
you don't want to rely on defaults changing underneath you.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2017-04-20 21:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 21:03 [Qemu-devel] question about block size and virtual disks Chris Friesen
2017-04-20 21:21 ` Eric Blake [this message]
2017-04-21 16:26 ` Chris Friesen
2017-04-25 11:33 ` 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=a09762ce-092f-6fb1-6cc3-08a94a3c3dd1@redhat.com \
--to=eblake@redhat.com \
--cc=chris.friesen@windriver.com \
--cc=qemu-devel@nongnu.org \
/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).