add virtio single-machine testing framework

[emil_etsalapatis.com]

Summary

Testing virtio drivers like virtiofs is currently not possible without host/guest
cooperation, which is impractical in a CI environment. Introduce a virtio debug transport
that allows device emulation in the same machine as the driver.

Test Plan

WIP

[asomers]

I think you need to add a definition for the virtio_dbg module in sys/modules. Oh, and how do you use it? Eventually we want ATF tests, of course. But I assume for now you've been manually using it somehow?

tests/sys/virtio/Makefile

1

You need to add these definitions. PACKAGE determines which file set in the DVD the file will belong to. The other too ensure that the file will be installed into the correct location.

[emil_etsalapatis.com]

In D45370#1035488, @asomers wrote:

I think you need to add a definition for the virtio_dbg module in sys/modules. Oh, and how do you use it? Eventually we want ATF tests, of course. But I assume for now you've been manually using it somehow?

Will do, I have been building it as part of the kernel so that's probably why it didn't need a definition in sys/modules. I have been running this manually.

I've been thinking on how to get this code to be more reviewable. Should I maybe try to get it published as a port instead of submitting it as a patch to src/? Most of this code is self-contained, and its size means it will be next to impossible to review in its current state. If we go down the port route, only changes we would be applying to src/ would be non-functional - most would be about turning some static functions global.

Alternatively, I can break this diff apart, get the virtio-dbg transport reviewed since it is more reasonably sized, and either spin off the userspace device emulation component as a port or introduce it later. Which do you think is more reasonable?

[asomers]

Will do, I have been building it as part of the kernel so that's probably why it didn't need a definition in sys/modules. I have been running this manually.

I've been thinking on how to get this code to be more reviewable. Should I maybe try to get it published as a port instead of submitting it as a patch to src/? Most of this code is self-contained, and its size means it will be next to impossible to review in its current state. If we go down the port route, only changes we would be applying to src/ would be non-functional - most would be about turning some static functions global.

Alternatively, I can break this diff apart, get the virtio-dbg transport reviewed since it is more reasonably sized, and either spin off the userspace device emulation component as a port or introduce it later. Which do you think is more reasonable?

Splitting it apart sounds good. Especially if there's some way to exercise the virtio-dbg transport without the userspace device emulation. Then splitting it apart would be a very good idea.

[emil_etsalapatis.com]

In D45370#1038548, @asomers wrote:

Will do, I have been building it as part of the kernel so that's probably why it didn't need a definition in sys/modules. I have been running this manually.

I've been thinking on how to get this code to be more reviewable. Should I maybe try to get it published as a port instead of submitting it as a patch to src/? Most of this code is self-contained, and its size means it will be next to impossible to review in its current state. If we go down the port route, only changes we would be applying to src/ would be non-functional - most would be about turning some static functions global.

Alternatively, I can break this diff apart, get the virtio-dbg transport reviewed since it is more reasonably sized, and either spin off the userspace device emulation component as a port or introduce it later. Which do you think is more reasonable?

Splitting it apart sounds good. Especially if there's some way to exercise the virtio-dbg transport without the userspace device emulation. Then splitting it apart would be a very good idea.

Sounds good, I'll break apart the transport code into separate diffs. We can test the transport w/o the emulation up to a point, e.g., the basic open/mmap/close code for the control device, so we can start with just virtio-dbg and go from there.