On 2016/1/25 21:59, rkrcmar@xxxxxxxxxx wrote:
2016-01-25 09:49+0800, Yang Zhang:
On 2016/1/22 21:31, rkrcmar@xxxxxxxxxx wrote:
2016-01-22 10:03+0800, Yang Zhang:
Not so complicated. We can reuse the wake up vector and check whether the
interrupt is multicast when one of destination vcpu handles it.
I'm not sure what you mean now ... I guess it is:
- Deliver the interrupt to a guest VCPU and relay the multicast to other
VCPUs. No, it's strictly worse than intercepting it in the host.
It is still handled in host context not guest context. The wakeup event
cannot be consumed like posted event.
Ok. ("when one of destination vcpu handles it" confused me into
thinking that you'd like to handle it with the notification vector.)
Sorry for my poor english. :(
So it relies on hypervisor to inject
the interrupt to guest. We can add the check at this point.
Yes, but I don't think we want to do that, because of following
drawbacks:
- Modify host's wakeup vector handler to send the multicast.
It's so complicated, because all information you start with in the
host is a vector number. You start with no idea what the multicast
interrupt should be.
We could add per-multicast PID to the list of parsed PIDs in
wakeup_handler and use PID->multicast interrupt mapping to tell which
interrupt we should send, but that seems worse than just delivering a
non-remapped interrupt.
(should have been "remapped, but non-posted".)
Also, if wakeup vector were used for wakeup and multicast, we'd be
uselessly doing work, because we can't tell which reason triggered the
interrupt before finishing one part -- using separate vectors for that
would be a bit nicer.
(imprecise -- we would always have to check for ON bit of all PIDs from
blocked VCPUs, for the original meaning of wakeup vector, and always
This is what KVM does currently.
either read the PIRR or check for ON bit of all PIDs that encode
multicast interrupts; then we have to clear ON bits for multicasts.)
Also, most part of work is covered by current logic except checking the
multicast.
---
There might be a benefit of using posted interrupts for host interrupts
when we run out of free interrupt vectors: we could start using vectors
by multiple sources through posted interrupts, if using posted
Do you mean per vcpu posted interrupts?
interrupts is the fastest way to distinguish the interrupt source.
--
best regards
yang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
