Harvey only works with 9P2000, QEMU virtio wants 9P2000.u or .L

[dmgolubovsky]

I got some progress with virtio, but run into a problem of 9P version incompatibility with QEMU.

The 9P version that Harvey supports is hardcoded in fcall.h

#define VERSION9P       "9P2000"

In QEMU, (hw/9pfs/virtio-9p.c) the only versions recognized are:

    if (!strcmp(version.data, "9P2000.u")) {
        s->proto_version = V9FS_PROTO_2000U;
    } else if (!strcmp(version.data, "9P2000.L")) {
        s->proto_version = V9FS_PROTO_2000L;
    } else {
        v9fs_string_sprintf(&version, "unknown");
    }

If I try to mount a virtio connection I get error "bad 9P version returned from the server". If I change the string in fcall.h to 9P2000.u everything else dies.

The mount syscall does not currently accept any flags that could be passed to devmnt to adjust the negotiated version of 9P. What could be the best way to handle this?

Thanks.

[rminnich]

I think we need to find whatever person broke QEMU 9p support, since they clearly don't understand how 9p works. There is NO REASON for that requirement, unless you can prove otherwise. Or I need to see a convincing reason that harvey should add 9p2000.[uL] support, which support was ONLY intended for unix systems, which harvey is not.

So the right way to handle this is to fix QEMU. Harvey's not broken. QEMU is.

Also, I think it's a good idea to get your changes up as PRs. Reviews are a good way to make sure you're staying on the right trail. If you're changing VERSION9P in harvey, you are definitely on the wrong trail.

[rminnich]

This not a harvey bug. This is a qemu limitation. You can only fix this by writing a new devmnt for 9p2000.l, and the writing all the RPC support too. I'm going to guess that's more than you planned. If you want a working 9p2000 support from a VMM, try https://github.com/penberg/linux-kvm/blob/e325f3e77e782a561e5c53ad582b0ac088573a59/net/9p/client.c#L98

But I'm curious why you're trying 9p on virtio before you get the virtio support in to harvey.

[rminnich]

I talked to my QEMU contact and basically they don't support 9p2000 because they did not need it for linux clients. There's no pushback on fixing QEMU. So I'd suggest you focus on virtio-net for now, ignore virtio-9p, and I'll try to fix QEMU.

[rminnich]

If you really want virtio-9p, then use the lkvm tool, which gets it right, not QEMU, which is wrong.

[dmgolubovsky]

Ron

Thanks for your reply. The reason I am trying to get virtio-9p working first is because my far reaching goal is to have virtualized Harvey talk to the virtualization host primarily/natively over 9p; this would pave the path to have the host's window system or GPU work natively for Harvey, maybe even network stack from the host could be brought into Harvey's namespace (via proxy, not sure if it could be more efficient than emulated network adapter, but worth trying, etc). Same with other host's devices; they could be uniformly presented to Harvey as 9p namespaces. So it was not trying 9p before virtio support for Harvey, it is my vision how virtio needs to be supported, 9p first.

RE lkvm: yes, I am aware of this, and was about to look into this option next. How is ACPI emulation by lkvm (is there any?) compatible with the current Harvey code?It can be the solution though, to have a specialized virtualizer for Harvey which provides its better integration with host resources while stock QEMU only solves the general tasks.

Per QEMU specifics of 9p. Indeed, it was written with Linux only in mind. Its implementation is not documented anywhere, I had to go back and forth over LXR to understand the logic. The problem is that for each 9p request, 2 buffers have to be added to virtqueue, one is request, another for the response. This makes sense because reduces the number of virtqueue kicks to one per request. But it then requires strict order of write-read operations on the handle serving 9p. In Linux, 9p virtio transport never surfaces into a handle, it goes directly from VFS where such ordering can be maintained. In Harvey case, mounts working via devmnt (single-threaded per connection as I see it) probably may be brought to such order, however multithreaded clients like aux/9pcon may send read request ahead of write, which requires complicated logic in the transport, that is, queue all requests (write and read) until there are at least one write and one read request waiting, then they can be added to virtqueue. At some moment this can come out of sync, cause delays or deadlocks. So indeed, QEMU implementation of 9p is not ideal for Harvey.

BTW I tried hard to find any other virtio-9p implementation than Linux; even major Unices (*BSD) do not have it while virtio-net and virtio-sd can be found.

Someone tried to submit a patch to QEMU (in 2011) to make it recognize legacy 9p, but the patch apparently was not accepted. https://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg01622.html

RE: pull requests: I can push what I have now, it went through some cleanup, there is a rudimentary mechanism to separate "flavors" of various virtio devices' logic for independent development, however it is far from working. All I have now is to issue a mount command on a virtqueue, and have protocol version negotiation which fails. So I now have working interaction with virtqueue, can push buffer, can get interrupt, can resume process, but that's it. Most of 9front code is gone though, so one less worry about someone else's license.

[rminnich]

Let's get virtio in first. Then let's look at virtio-9p. that's my suggestion.

[elbing]

How is this now?

[dmgolubovsky]

Resolved by #386.