From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Ideas for PV on SeaBIOS - flush/barrier in QEMU Date: Thu, 19 May 2011 13:00:36 -0400 Message-ID: <20110519170036.GA14215@dumpdata.com> References: <4DD4EC2502000078000420F7@vpn.id2.novell.com> <20110519082047.GA27118@whitby.uk.xensource.com> <1305797813.20907.175.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1305797813.20907.175.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Tim Deegan , Daniel Castro , "xen-devel@lists.xensource.com" , "seabios@seabios.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org > As an aside we will also need to handle the case where the guest is not > PV aware and hence uses the emulated devices and never triggers any of > the above activities. So we need to ensure that the backends are sync'd > even if none of the above takes place. The PV devices will remain open > but that needn't be a problem if the guest never uses them. > > Possibly this means making sure all writes via this PV interface go > straight to disk (using the appropriate barriers) or by having qemu do >>From an userspace perspective that is funneled via fdatasync. On 2.6.39 that becomes REQ_FLUSH|REQ_FUA which is correct-ish. > the necessary flush when the emulated device is first used. Hm, what is the HVM backend for 'phy' in QEMU mode? I've been using 'file' which translates to qdisk (which does the proper fdatasync on flush, thought not the proper flush on barrier as the 2.6.39 fdatasync does not do the old-style barrier flush).