-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Network implementation #355
base: master
Are you sure you want to change the base?
Conversation
iommu_platform=trueLines 246 to 256 in 32af349
This comment was generated by todo based on a
|
,iommu_platform=trueLines 273 to 283 in 32af349
This comment was generated by todo based on a
|
More interesting debug.SunriseOS/libuser/src/pci/capabilities.rs Lines 31 to 41 in 32af349
This comment was generated by todo based on a
|
Lazily read the Vendor-Specific Capabilities?Currently, vendor-specific capabilities are eagerly read and kept in a vector. This is likely suboptimal. Ideally, we should get some type that we can call functions on to get u32s from. SunriseOS/libuser/src/pci/capabilities.rs Lines 124 to 134 in 32af349
This comment was generated by todo based on a
|
DMARLines 170 to 180 in 32af349
This comment was generated by todo based on a
|
Schedule out?Lines 187 to 197 in 32af349
This comment was generated by todo based on a
|
TmpLines 145 to 155 in 32af349
This comment was generated by todo based on a
|
Is it OK to assume device is ack'd in VirtioNet::init?Lines 163 to 173 in 32af349
This comment was generated by todo based on a
|
MSI-X Vector Configuration.Lines 179 to 189 in 32af349
This comment was generated by todo based on a
|
Support VIRTIO_NET_F_MQLines 184 to 194 in 32af349
This comment was generated by todo based on a
|
Setup ctrl_vqLines 191 to 201 in 32af349
This comment was generated by todo based on a
|
Generate random macLines 217 to 227 in 32af349
This comment was generated by todo based on a
|
Generate random macLines 270 to 280 in 32af349
This comment was generated by todo based on a
|
Instead of allocating a new vec, use scatter-gather IO.Lines 327 to 337 in 32af349
This comment was generated by todo based on a
|
Blow up if cur_free_head == EOL marker.SunriseOS/virtio/src/virtqueue.rs Lines 117 to 127 in 32af349
This comment was generated by todo based on a
|
Blow up if cur_free_head == EOL marker.SunriseOS/virtio/src/virtqueue.rs Lines 135 to 145 in 32af349
This comment was generated by todo based on a
|
Remove the InPointer/InBuffer/OutPointer/OutBuffer types as they did not have a reason to exist in the new object system. Instead, the pop_buffer family of function now return a raw reference, whose lifetime is selected by the caller. This simplifies the code a fair bit.
Share the PCI implementation across multiple drivers by moving it to libuser.
The GetSystemTick syscall returns a monotonic up-counter representing a frequency of 19200000 Hz. Note that none of our clocks actually run at this frequency (HPET is likely to have a much higher frequency, while PIT is likely to have a much, much, much lower frequency). As such, we have to do some maths. In order to implement GetSystemTick, the KERNEL_TIMER_INFO now contains a get_tick function pointer. When the kernel timer gets selected, it should provide an implementation of that function as a parameter to set_kernel_timer_info.
Turns out, the spec we were basic our PCI implementation on previously was probably a draft. After updating to a more correct spec, things started working a lot better, unsurprisingly.
We now support auto-selected (smart) buffers. When the user fetches an interface containing methods with smart-buffers, it will fetch the Pointer Buffer Size. Depending on whether the smart buffer fits the pointer buffer or not, it will be passed as either a Pointer or a Buffer. In order to implement this, a simple dispatch for Control messages was implemented. The QueryPointerBufferSize function was implemented as well. The pointer buffer size is fetched and cached on interface creation. Only interfaces actually containing smart buffers will fetch this information, to avoid doing a bunch of useless IPC requests.
Let's talk to the internet!
Currently,
virtio
is able to talk to a TCP server.virtio
is all hardcoded though, so what's left to do is:virtio
into two services:virtio
proper andvirtio-net
.virtio
is responsible for handling the generic virtio interface. All the virtio devices are owned by thevirtio
sysmodule, which will expose an IPC interface to interact with them (Feature negociation, setting up the virtqueues, pushing/popping buffers, waiting for an event, etc...)virtio-net
will contain the drivier for virtio-net interfaces, the glue to make it work withsmoltcp
, and expose an IPC interfacebsd
which will expose the BSD Socket interface we're all familiar with.bsd
interface on top of smoltcp. Smoltcp's interface is very different from the standard BSD socket, so we might need to do quite a bit of glue here.shell
to test the implementation.