qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: A new direction for vmchannel?


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: A new direction for vmchannel?
Date: Sat, 24 Jan 2009 15:22:07 -0600
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Jamie Lokier wrote:
Anthony Liguori wrote:
Thinking more about this, the difficulty is that poll() only has useful semantics when you're dealing with a buffered stream of some sort. That is, poll() is only really capable of asking whether there is data pending in your read buffer.

With 9P, you have to explicitly send a read request. You can implement buffered IO by simply sending constant read requests such that there is always one read request pending. I don't think it's useful to do this in the kernel.

In linux/Documentation/fs/9p.txt:

  nodevmap      do not map special files - represent them as normal files.
                This can be used to share devices/named pipes/sockets between
                hosts.  This functionality will be expanded in later versions.

Does this mean it can provide the semantics of a named pipe
or unix domain socket over 9p?

Eric will have to correct me if I'm wrong, but I believe that that bit of functionality is not yet implemented (although it's been discussed).

But what about non-Linux guests?

The plan for non-Linux guests is to expose the 9P protocol stream down to userspace and provide a library with posix-like file system semantics. For instance kvmfs_open(), kvmfs_read(), kvmfs_write(), etc. Applications that care about portability can use this library on Linux and non-Linux.

For non-Linux guests where we can get a kernel driver in, the driver will feed the 9P stream directly to userspace. For guests that we cannot get a kernel driver in, we can stream 9P to the guest via TCP, serial port, etc. This requires some config in the guest's userspace and may require some admin intervention but that's the price you pay for avoiding a kernel module.

Unfortunately, there's no way to do async IO in userspace that doesn't suck so that would make this pretty difficult. We could use a thread pool, but that's somewhat soul crushing and doesn't scale well. I think that puts a requirement on v9fs to support linux-aio.

It sounds like a weird mashup of unix regular file behaviour and unix
socket behaviour.  Poll doesn't work, aio might, but you can
read/write like a stream?  Very un-unix.

Right.  We can certainly modify v9fs to make poll() behave more naturally.

Regards,

Anthony Liguori

Even if it can be made to work, that's sufficiently un-unix to reduce
its general utility with existing scripting languages, existing
monitoring programs etc.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to address@hidden
More majordomo info at  http://vger.kernel.org/majordomo-info.html





reply via email to

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