qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Pass the drive's readonly attribute to the gues


From: Gleb Natapov
Subject: Re: [Qemu-devel] [PATCH] Pass the drive's readonly attribute to the guest OS
Date: Thu, 15 Oct 2009 12:11:31 +0200

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.

--
                        Gleb.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]