2016-01-27 10:07+0800, Yang Zhang: > On 2016/1/27 2:22, rkrcmar@xxxxxxxxxx wrote: >>2016-01-26 09:44+0800, Yang Zhang: >>>On 2016/1/25 21:59, rkrcmar@xxxxxxxxxx wrote: >>>>>> 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 >>>> 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. >> >>We could reuse the setup that gets us to wakeup_handler, but there is >>nothing to share in the handler itself. Sharing a handler means that we >>always have to execute both parts. > > I don't quite understand it. There is nothing need to be modified for wakeup > logic. The only thing we need to do is add the checking before the vcpu pick > up the pending interrupt(This is happened in VCPU context, not in handler). I see, there are few problems with that. >>We must create new PID anyway and compared to the extra work needed for >>multicast handling, a new vector + handler is a relatively small code >>investment that adds clarity to the design (and performance). > > No new PID is needed. If the target vcpu is running, no additional work is > required in wakeup handler. If target vcpu is not running, the current logic > will wake up the vcpu, then let vcpu itself to check whether pending > interrupt is a multicast and handle it in vcpu's context. We do need a new PID. The existing VCPU PID switches between wakeup vector and notification vector, so if the VCPU was running when the device triggered an interrupt, we'd deliver the posted interrupt without exiting, but we need to handle the interrupt in the host. => We need at least one PID that is never set to notification vector. Reusing VCPU's PIRR is in new PID(s) is not doable. Parsing PIRR would be our only option of recognizing multicast interrupts and if the guest configured many sources to send the same vector, we'd have to do unacceptable things to tell which one was triggered. => We also need at least on one new PIRR. Handling the interrupt in VCPU context doesn't pose any advantage and we even want to do it outside, because all VCPUs can be running when the interrupt arrives and can therefore be posted further. I hope I covered other disadvantages of PIDs and PIRRs earlier. -- 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
