Jorge Pereira

> > Dynamically enable/disable Maintenance IRQ for the underflow condition based on the number of pending LRs. > > Can you elaborate what you mean here? I think we should...

> > Adding a bitmap for each vCPU object with 2-bits per pending vIRQ, max 1024 vIRQ as spec mentions. > > Is this for the state that is currently...

> > New vCPU syscall to bind an IRQHandler cap to a vCPU cap. (Instead of Notification Object, we can use a vCPU Object) > > I was thinking that...

> One reason this would be hard to implement though is if the VCPU wasn't active and associated with the currently running thread, it's not immediately obvious what the kernel...

> > > Separation of Priority-drop from Deactivation (Feature supported by GICv2/3/4). > > > > > > Yes, I've been trying to find time to set up some benchmarks...

> For tracking IRQ enabled/disabled state and pending/active? We can discuss about emulation as well, let it be in the end :) Overflow list per vCPU is the main requirement....

> There is a list of proposed features, and people with virtualisation background probably don't need more than that, but for me it's currently unclear what problems we're trying to...

> One thing we probably should also consider is that how the GICv4 with directly injected virtual LPIs will reduce the overhead. We don't see many platforms with GICv4 today....

> It seems like this would also require the kernel to handle wfi/wfe trapping in the guest? Currently if WFI's are trapped, the VCPU thread becomes blocked on a fault-ep...