All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Evgeny Yakovlev <eyakovlev@virtuozzo.com>,
	"Denis V. Lunev" <den@openvz.org>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>,
	Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	John Snow <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v6 3/6] tests: in IDE and AHCI tests perform DMA write before flushing
Date: Fri, 15 Jul 2016 11:23:57 -0600	[thread overview]
Message-ID: <57891C2D.5010004@redhat.com> (raw)
In-Reply-To: <578899F3.3080605@virtuozzo.com>

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

On 07/15/2016 02:08 AM, Evgeny Yakovlev wrote:

>>> + * Write sector 0 with random data to make AHCI storage dirty
>> If we ever have a case where we open a disk without specifying -raw, the
>> random data _might_ resemble some other format and cause probe to
>> misbehave; as such, we also have code in the block layer that
>> specifically prevents writes to sector 0 for some data. Should you pick
>> a different sector than 0, so as to avoid any (remote) possibility that
>> the random data could change probe results or be rejected?
>>
> 
> Not sure if i understand the problem you're referring to here. Those are
> blkdebug tests, those disks are created, emulated with blkdebug backend,
> flushed and then thrown away. So is there really any possibility for
> reopening the image and accidentally parsing a partition table in sector 0?
> 
> Also, not sure what you mean by "code in the block layer that
> specifically prevents writes to sector 0 for some data". Can you explain
> that bit, because it sounds pretty scary. How can we deny guest VM to
> write anything to sector 0 on its emulated disk?

Read block/raw_bsd.c:raw_co_writev_flags() for the gory details.  If the
guest ever gets a raw format driver because the user forgot to say
'--format $foo', then we prevent the guest from writing anything into
sector 0 that would be probed as non-raw.  It means there are only a
handful of patterns that the guest cannot write into the first sector,
but it IS a non-zero number of patterns.  How the guest behaves if such
a write is attempted depends on the error policy you have on that
device; it might show up as an EIO error to the guest, or it might stop
the guest from executing and raise a qemu event to the management
application, but the point is that we actively prohibit some writes to
sector 0 on a probed raw disk.  Using any sector other than 0 doesn't
have this limitation, or you can ensure that your test ALWAYS passes the
appropriate --format $foo so that the disk is never probed as another
way to avoid limitations on sector 0.


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2016-07-15 17:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14 12:29 [Qemu-devel] [PATCH v6 0/6] block: ignore flush requests when storage is clean Denis V. Lunev
2016-07-14 12:29 ` [Qemu-devel] [PATCH v6 1/6] ide: refactor retry_unit set and clear into separate function Denis V. Lunev
2016-07-14 12:29 ` [Qemu-devel] [PATCH v6 2/6] ide: set retry_unit for PIO and FLUSH requests Denis V. Lunev
2016-07-14 12:29 ` [Qemu-devel] [PATCH v6 3/6] tests: in IDE and AHCI tests perform DMA write before flushing Denis V. Lunev
2016-07-14 16:05   ` Eric Blake
2016-07-15  8:08     ` Evgeny Yakovlev
2016-07-15 17:23       ` Eric Blake [this message]
2016-07-15 17:44         ` Evgeny Yakovlev
2016-07-14 12:29 ` [Qemu-devel] [PATCH v6 4/6] block: ignore flush requests when storage is clean Denis V. Lunev
2016-07-14 12:29 ` [Qemu-devel] [PATCH v6 5/6] tests: removed skipped flushes from block test traces Denis V. Lunev
2016-07-14 16:06   ` Eric Blake
2016-07-15  8:11     ` Evgeny Yakovlev
2016-07-14 12:29 ` [Qemu-devel] [PATCH v6 6/6] tests: changed block job ready event generation order Denis V. Lunev
2016-07-14 16:07   ` Eric Blake
2016-07-14 19:46     ` John Snow

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=57891C2D.5010004@redhat.com \
    --to=eblake@redhat.com \
    --cc=den@openvz.org \
    --cc=eyakovlev@virtuozzo.com \
    --cc=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.