On 5/12/22 3:38 PM, Claudio Fontana wrote: > On 5/11/22 7:46 PM, Daniel P. Berrangé wrote: >> On Wed, May 11, 2022 at 07:31:45PM +0200, Claudio Fontana wrote: >>> That's great, I love when things are simple. >>> >>> If indeed we want to remove the copy in libvirt (which will also mean >>> explicitly fsyncing elsewhere, as the iohelper would not be there anymore >>> to do that for us on image creation), >>> with QEMU having a "file" protocol support for migration, >>> >>> do we plan to have libvirt and QEMU both open the file for writing >>> concurrently, with QEMU opening O_DIRECT? >> >> For non-libvirt users, I expect QEMU would open the >> file directly . For libvirt usage, it is likely >> preferrable to pass the pre-opened FD, because that >> simplifies file permission handling. >> >>> The alternative being having libvirt open the file with >>> O_DIRECT, write some libvirt stuff in a new, O_DIRECT- >>> friendly format, and then pass the fd to qemu to migrate to, >>> and QEMU sending its new O_DIRECT friendly stream there. >> >> Yep. > > Currently I am working on this part, and I can use my prototype to test that > the Direct part of the I/O works.
Just as a follow up and heads up that I am reworking the Image Write and Read code in qemu_saveimage.c and while doing that I see quite a few things that need improvement, especially missing validations on lengths etc. Ciao, Claudio > I can split things more to be able to provide more generally useful parts to > the series, > that we can use to test out things while the qemu stuff is hopefully also > tackled. > > Thanks, > > Claudio > >> >>> In any case, the expectation here is to have a new >>> "file://pathname" or "file:://fdname" as an added feature in QEMU, >>> where QEMU would write a new O_DIRECT friendly stream >>> directly into the file, taking care of both optional >>> parallelization and compression. >> >> I could see several distinct building blocks >> >> * First a "file:/some/path" migration protocol >> that can just do "normal" I/O, but still writing >> in the traditional migration data stream >> >> * Modify existing 'fd:' protocol so that it fstat()s >> and passes over to the 'file' protocol handler if >> it sees the FD is not a socket/pipe >> >> * Add a migration capability "direct-mapped" to >> indicate we want the RAM data written/read directly >> to/from fixed positions in the file, as opposed to >> a stream. Obviously only valid with a sub-set >> of migration protocols (file, and fd: if a seekable >> FD). >> >> * Add a migration capability "bypass-cache" to >> indicate we want O_DIRECT to bypass host I/O >> cache. Again limited to some migration protocols >> >> >> With regards, >> Daniel >> >
