On Sat, Jun 01, 2019 at 06:12:16PM -0500, Katherine Rohl wrote: > Couple questions: > > > This means no interrupt will be injected. I'm not sure if that's what you > > want. > > See vm.c: vcpu_exit_inout(..). It looks like you may have manually asserted > > the > > IRQ in this file, which is a bit different than what we do in other > > devices. That > > may be okay, though. > > The device can assert zero, one, or two IRQs depending on the state of the > input ports. Are we capable of asserting two IRQs at once through > vcpu_exit_i8042? >
Yes, just assert/deassert what you want and it should drive the PIC state machine accordingly. LMK if that doesn't work. Assert followed by immediate deassert for edge triggered, and assert followed by deassert after ack for level triggered. I think all these are edge triggered though. > > For this IRQ, if it's edge triggered, please assert then deassert the line. > > The i8259 code should handle that properly. What you have here is a level > > triggered interrupt (eg, the line will stay asserted until someone > > does a 1 -> 0 transition below). Same goes for the next few cases. > > Would asserting the IRQs through the exit function handle this for me if > that’s possible? The return-to-vmm path can assert one single interrupt via returning something other than 0xFF from the exit handler in vmd. But if you need two, you'll need to either rework that logic (and fix all the other devices) or just assert/deassert one in the exit handler function and have the return-to-vmm path handle the other. Your call. Note - it is probably a good idea to rework the logic at some point because the current model can only handle "inject this edge triggered interrupt", and not other interesting scenarios we may need later like "assert this level triggered interrupt" or being able to flexibly configure a number of different interrupts (edge or level triggered). There is also no provision to handle deasserting something in the return-to-vmm path presently (that has to be handled in each device's I/O routine in vmd - yuck). > > > Also, please bump the revision in the vcpu struct for send/receive > > as we will be sending a new struct layout now. > > Where exactly? The file revision?
