| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no need for every interface on a router to have it's own
unique IP. Using link-local addresses, we can assign every interface
on a single router the same IP, and save the effort of
adding/subtracting one all the time to infer the address of one side
of a link from the other.
This means that routers and clients are both only interested in what
the IP of the client should be, since that's the only thing that is
different between different links. So we change our MAC format to
communicate the client IP to both sides. If we just made the whole
NIC portion of the MAC the last three octets of an IP address like we
did before, then both ends of the link would have the same MAC, so we
still need to set a bit to encode whether a MAC is at the router side
of the link or the client side. I've decided to simplify the
implementation by using the most significant bit of the NIC part for
that, and just declaring the rest of that octet to be reserved. This
way, no calculation is required in the guests -- they just need to
look at the last two octets. And we can still identify 65536 links in
this scheme, which should be enough for anybody, right?
Message-Id: <20210513201323.2087344-1-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following operations are available to us in /sys/bus/pci/drivers/vfio-pci:
bind, unbind, new_id, remove_id
bind and unbind control attachment of a device to a driver.
new_id and remove_id control whether a device should be considered
"supported" by a driver.
But when an unassigned device is newly supported by a driver, the
kernel will automatically bind it to that driver. We were relying on
the new_id operation binding the device to the driver in this way.
But if the driver is in the supported list, but not bound to anything,
this won't happen. new_id won't do anything, because it's already in
the supported list. So we can't rely on new_id binding for us, and
need to try bind as well (at least if new_id fails).
To reproduce:
echo 8086 1502 > /sys/bus/pci/drivers/vfio-pci/new_id
echo 0000:00:19.0 > /sys/bus/pci/drivers/vfio-pci/unbind
(Use lspci -nn to find the right values for your hardware.)
This will leave you with a device that is supported by vfio-pci but
not bound to it, which would previously cause vm-net to fail to start,
but should not after this change.
Message-Id: <20210421101605.20790-1-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
|
|
This produces a shell script that sets up a host system for running
the VMs under sys-vms, and then starts an s6-rc service manager that
can run the VMs. This mirrors how I imagine things working on the
eventual Spectrum host system.
With s6-rc, we can express dependencies between services, so when
vm-app is started, vm-net will automatically be started too if it
isn't already running.
One thing I haven't implemented yet is readiness notification.
Ideally, the cloud-hypervisor instance running the router VM would be
able to tell s6 once its control socket was listening, and s6 wouldn't
consider it to be up until that point. But it can't do that at the
moment, so s6 considers it to be up immediately, and starts vm-app
right away. This means that vm-app will usually fail once due to
vm-net's socket not existing, and then immediately be restarted and
work the second time. I think that's fine for now.
The serial console for vm-app will be connected to the terminal. To
interact with vm-net instead, the serial console for vm-app can be
disconnected uncommenting the two commented out lines in its
definition, and the serial console for vm-net can be enabled by
commenting the redirfd that disables its stdin, and uncommenting the
--serial line.
We're using cloud-hypervisor instead of crosvm for vm-net because
cloud-hypervisor supports adding virtual ethernet devices at runtime
and crosvm doesn't, and it'll be important to be able to add
connections to new VMs as applications are started on a running
system.
The TODO about removing the device from cloud-hypervisor is going to
stay a TODO for now, because the solution is quite complicated: if we
tell cloud-hypervisor to remove the device from the VM using its API,
it'll still be trying to read from it for a short time after
returning, so we'll still get read errors in cloud-hypervisor after we
delete the TAP. I think the only good way to handle this will be to
use a non-persistent TAP device, so that it automatically gets cleaned
up by the kernel when cloud-hypervisor is done with it. But to do
that, cloud-hypervisor will have to be able to add TAPs from file
descriptors at runtime, which will probably be quite difficult to fit
into its HTTP API -- at least it's over a Unix socket.
Message-Id: <20210411115740.29615-17-hi@alyssa.is>
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
Tested-by: Cole Helbling <cole.e.helbling@outlook.com>
|