From: Kevin Wolf <kwolf@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Naphtali Sprei <nsprei@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Pass the drive's readonly attribute to the guest OS
Date: Thu, 15 Oct 2009 12:18:44 +0200 [thread overview]
Message-ID: <4AD6F704.2020508@redhat.com> (raw)
In-Reply-To: <20091015101131.GH30889@redhat.com>
Am 15.10.2009 12:11, schrieb Gleb Natapov:
> On Thu, Oct 15, 2009 at 12:05:41PM +0200, Kevin Wolf wrote:
>>>>>>>> If the right response to a write on a read-only device is defined in the
>>>>>>>> specification (and it most probably is), we should still give the right
>>>>>>>> response, even though the OS is doing something wrong.
>>>>>>>>
>>>>>>> And since our response to write error may be pausing a VM we shouldn't
>>>>>>> allow this to be triggered by a guest OS.
>>>>>>
>>>>>> I thought we only pause the VM if we get an host IO error? But if you do
>>>>>> want to stop it for all errors, you shouldn't start suppressing errors
>>>>>> so that it doesn't stop.
>>>>>>
>>>>> We pause only on host IO errors, but if we open underlying file as
>>>>> read only (do we?) and try to write into it we will get an IO error
>>>>> in the host.
>>>>
>>>> No, we'll return an error before a write request to the host is even issued.
>>>>
>>> Who is "we"? If "we" == "bdrv_write()/dma_bdrv_write()" then it's all the same.
>>> Upper layers don't actually care why block driver failed.
>>
>> Right, "we" is the qemu block layer. If the devices don't use the error
>> code returned, they better should be fixed, I think?
>>
> Fixed in what way? There is an option to pause VM on any write error. If
> block layer returns write error for whatever reason VM will be paused.
> If scsi/ide/virtio knows that the media is read only it shouldn't
> issue writes to block layer, but handle it like real HW would.
Ok, I agree if you want to do it this way. How it's done I really don't
care too much, but in the end the guest OS should see the right error. I
had the impression that Naphtali and you wanted to silently ignore
writes to a read-only disk, which would be just wrong.
Kevin
next prev parent reply other threads:[~2009-10-15 10:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-14 15:52 [Qemu-devel] [PATCH] Pass the drive's readonly attribute to the guest OS Naphtali Sprei
2009-10-14 15:57 ` Gerd Hoffmann
2009-10-14 15:59 ` Naphtali Sprei
2009-10-14 16:07 ` Gerd Hoffmann
2009-10-14 16:32 ` Naphtali Sprei
2009-10-14 16:40 ` Naphtali Sprei
2009-10-15 9:36 ` Kevin Wolf
2009-10-15 9:43 ` Gleb Natapov
2009-10-15 9:50 ` Kevin Wolf
2009-10-15 9:54 ` Gleb Natapov
2009-10-15 9:55 ` Kevin Wolf
2009-10-15 10:01 ` Gleb Natapov
2009-10-15 10:05 ` Kevin Wolf
2009-10-15 10:11 ` Gleb Natapov
2009-10-15 10:18 ` Kevin Wolf [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-10-29 9:42 Naphtali Sprei
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=4AD6F704.2020508@redhat.com \
--to=kwolf@redhat.com \
--cc=gleb@redhat.com \
--cc=nsprei@redhat.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 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.