Hi - On 2016-06-08 at 10:22 Kyle Milka <[email protected]> wrote: > diff --git a/tests/vmm/vmrunkernel.c b/tests/vmm/vmrunkernel.c > @@ -206,14 +207,15 @@ void timer_thread(void *arg) > // FIXME. > volatile int consdata = 0; > > -static void virtio_poke_guest(void) > +static void virtio_cons_poke_guest(void) > { > set_posted_interrupt(0xE5); > ros_syscall(SYS_vmm_poke_guest, 0, 0, 0, 0, 0, 0); > } > > static struct virtio_mmio_dev cons_mmio_dev = { > - .poke_guest = virtio_poke_guest > + .poke_guest = virtio_cons_poke_guest, > + .irq = 32 > };
What's the connection between this irq field (32) and the posted interrupt vector (0xe5)? Same goes for virtio-net. Does the PIR vector (e.g. e5, e6) encode which device to look at or something? I see that we pass irq to linux on the command line. Are those the actual IRQ vectors in Linux? If so, 29 seems a little weird (since it's less than 32). > @@ -585,6 +633,10 @@ int main(int argc, char **argv) > cons_mmio_dev.vqdev = &cons_vqdev; > vm->virtio_mmio_devices[VIRTIO_MMIO_CONSOLE_DEV] = &cons_mmio_dev; > > + net_mmio_dev.addr = cons_mmio_dev.addr + PGSIZE; As we add more devices, some of which might be absent, we'll probably want to do something other than "previous + PGSIZE". We're basically allocating MMIO addrs. It's fine for now. > + net_mmio_dev.vqdev = &net_vqdev; > + vm->virtio_mmio_devices[VIRTIO_MMIO_NETWORK_DEV] = &net_mmio_dev; > --- /dev/null > +++ b/user/vmm/virtio_net.c > @@ -0,0 +1,120 @@ > +/* Virtio helper functions from linux/tools/lguest/lguest.c > + * > + * Copyright (C) 1991-2016, the Linux Kernel authors > + * Copyright (c) 2016 Google Inc. > + * > + * Author: > + * Rusty Russell <[email protected]> > + * Kyle Milka <[email protected]> If it's possible, can you bring in the original lguest functions in a separate patch, then make your changes in another one? That would help me see what's different from what lguest did. Mike did this for the other virtio bits, and it helped a lot to understand what was going on and catch potential issues. One way you could do that would be to have this patch, minus virtio_net.c, but with stubs elsewhere for net_receiveq_fn/transmit_fn. Then add in the lguest code in another commit, then port it in a third commit. If you can't easily reconstruct lguest's net_recv/transmit, then it's OK as is. > +#include <stdlib.h> > +#include <vmm/virtio.h> > +#include <vmm/virtio_mmio.h> > + > +/* net_receiveq_fn receives packets from the virtio networking device through > + * the _vq virtio queue. > + * > + * TODO(kmilka): Not working until we have networking capabilities. > + */ > +void net_receiveq_fn(void *_vq) Just to be clear, this is the *guest* receiving packets from the network, right? > + while (1) { > + head = virtio_next_avail_vq_desc(vq, iov, &olen, &ilen); > + > + if (olen) { > + free(iov); > + VIRTIO_DRI_ERRX(vq->vqdev, > + "The driver placed a device-readable buffer in > the console device's receiveq.\n" > + " See virtio-v1.0-cs04 s5.3.6.1 Device > Operation"); > + } > + /* Grab actual external packet > + * num_read = readv(0, iov, ilen); > + * if (num_read <= 0) > + * wait forever since we dont actually have > + * something from the network */ > + while (1); I know this is a stopgap til the network is working, but I have a helper for this. while(1) will spin forever, using up a core. Instead, use uthread_sleep_forever(). The uthread will block and never wake up. That should help out the VMM until we get rid of this. > +/* net_receiveq_fn transmits packets from the virtio networking device > through > + * the _vq virtio queue. That probably should be "net_transmitq_fn". Also, as above, I think it would clarify things to explicitly state the guest is transmitting. Barret -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
