qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional


From: Henrik Nordstrom
Subject: Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
Date: Wed, 8 Jun 2005 09:52:08 +0200 (CEST)

On Tue, 7 Jun 2005, John R. Hogerhuis wrote:

For the kind of thing I'm referring to is not usually very time
critical. The resolution is on the order of 15 to 30 minutes to an
hour... some stores get polled for data, the accounting system imports
the data and generates some reports which feed into other systems, etc.
Nothing particularly time critical.

Ok, so reading data from the guest may work in this situation, but you need to be careful to avoid races.

Updates in the other direction is harder however, unless vvfat is changed to emulate a floppy with floppy change notification and the guest has support for changing floppy "at random".

Of course, if I understand what you are saying it doesn't have to tell
vvfat though... all events pass through QEMU so you have a place to hook
events and there's no polling involved. The more stupid the guest's file
structure, the more feasible such a solution becomes. "Open/create" and
"write" and "seek" should be possible to recover, efficiently even, if
you maintain a hash table or other data structure which lets you go from
block # to file (or block # to free space).

I guess the event you would be missing is "close," but a idle timeout is
probably a decent heuristic. Also if the file is locked, that would have
to be mimiced.

The concept of "file" does not exist at this level, only blocks of data on a block device (hdd, floppy, cdrom etc, a long series of blocks to the size of the device).

To make it look like files qemu has to make it look like a block device with a block based filesystem on, and for write support the emulation must support any kind of modifications to the block level filesystem the guest may do.

There is several big issues involved in providing write support

a) On guest writes, the emulation must have a very good understanding of how the guest writes to the emulated filesystem to allow it to piece together the block level writes and map this to the files it is supposed to represent on the host.

b) On host writes it must detect changes in the directory and reflect this into the block level filesystem structure. You also have to battle with filesystem and block level caches in the guest to make the guest see the updated block level filesystem structure.

The only sane way of having a concept of files is to rely on the networked filesystems (SMB/NFS/FTP/whatever), but this obviously requires networking. Networked filesystem works on a file level.

Regards
Henrik




reply via email to

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