hv: Add 9P virtio peripheral #228
Conversation
|
Very cute. I like it :) I was going to say I'm not sure about putting this in the ADT, but on further thought there's no reason not to do that (as long as the mutation happens in Python, since we already have code for that there). So sure, why not! |
|
Just sort of direction-wise: I'm fine with anything in m1n1/the hypervisor as long as it helps with development. I don't think it should become a general-purpose hypervisor or veer off towards production usage, but sharing files with the host is very obviously useful for a ton of reasons (e.g. you can avoid building initramfses all the time for development, develop kernel modules and load/reload them from the guest without a full reboot, etc.). I've been doing this over sshfs in the past (host to guest, which sucks a bit), but the other way around with 9p should be nicer for a bunch of workflows. |
|
Okay, I implemented the hypervisor->ADT->FDT path to pass information on the existence of the virtio device, and added allocation of IRQ/register range. The allocation looks for numbers/ranges that are free per ADT -- for MMIO that should be foolproof, and I guess the AIC isn't to any degree shared with the coprocessors, so for IRQs that should be okay too. So, about usage: One passes a path and a tag to the hypervisor, so for example to export one tree under tag You need a |
| @@ -1114,6 +1182,10 @@ int kboot_prepare_dt(void *fdt) | |||
| return -1; | |||
| if (dt_disable_missing_devs("i2c", "i2c@", 8)) | |||
| return -1; | |||
| #ifndef RELEASE | |||
There was a problem hiding this comment.
Not sure if we want !RELEASE or some other gate here
|
Rebased |
|
Rebased |
|
Ping @marcan |
|
Looks good, can you fix the conflict so I can merge? |
|
Sure, thanks for the review! |
Add some minimal implementation of virtio peripherals. At the level of on-target hypervisor code we implement the MMIO layout and maintain virtqueues. Once a buffer is available, we break into the host proxyclient to deal with it. Specific device-classes of the virtio spec ought to be implemented in the proxyclient. Here the one device implemented is 9P transport, exporting the m1n1 source directory. Signed-off-by: Martin Povišer <povik@cutebit.org>
Used for sys.stderr later on. Signed-off-by: Martin Povišer <povik@cutebit.org>
So that one can check for children, like: >>> "/arm-io/aic" in u.adt True Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: Martin Povišer <povik@cutebit.org>
So that one knows what to put in reg properties. Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: Martin Povišer <povik@cutebit.org>
This is to fix OverflowError: Python int too large to convert to C ssize_t in case the upper bound of a range is 1<<64. Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: Martin Povišer <povik@cutebit.org>
|
Rebased (and removed a stray definition in |
This allows one to access host m1n1 sources from within the system running in hypervisor. Once you arrange for the virtio peripheral both in hypervisor code (
self.attach_virtio(Virtio9PTransport(), 0x2_2000_0000, 382)) and in the devicetree, you runto mount the sources on guest. One use case of it is using m1n1 regmaps over kernel's internal regmap structures (as alluded to by the extra commit).
Performance is not great since the hypervisor stops to handle each 9P call but it's not impractical.
Direction I think this should be expanded in:
Let me know if you think this is fine for inclusion.