On 2012-06-10 12:43, Abel Gordon wrote: > > > kvm-owner@xxxxxxxxxxxxxxx wrote on 10/06/2012 13:16:01: > >>> Yep, these are corner cases we should deal with but they are not part >>> of the common case/critical path. >>> >>>> I'm wondering if redirecting (to different cores) or masking (at >>>> device/IOAPIC/LAPIC level) of non-guest interrupts and only relying on >>>> preemption timer/NMI isn't simpler. Then you wouldn't have to shadow > the >>>> IDT. >>> >>> Yep, as we suggested in the paper, that could be also an alternative. >>> Is it really simpler ? Again, depends who you ask and what you need to >>> change. >>> All the alternatives have a set of pros and cons. >>> >> For sure. But avoiding the shadow IDT would likely mean avoiding >> userspace changes for KVM. And that means simplification. And avoid PCI >> dependencies. > > But you lose flexibility. Remember that if you don't shadow the IDT > you need at least one dedicated core that never uses ELI to handle > all the physical interrupts. With the shadow IDT, you could enable > ELI in all the cores. You need to program the preemption timer anyway. Once you leave some guest due to its expiry, you will re-enable the host IRQs and process them. > In addition, if you don't use the shadow IDT, host interrupts will not > be balanced across all the ELI cores. Thus, if you run many VMs/VCPU, you > might experience higher latency/bottlenecks or have scalability > problems unless you use a shadow IDT (depending on the workload, > offcourse). That might be an issue. My feeling is software-based ELI could be a transitional feature (until hardware supports it properly) and may focus more on static setups where you have dedicated cores for guests and separated I/O processing. In any case, I would suggest to start small, mostly self-contained, ie. with changes that stay within KVM as far as possible. If that is accepted, you could suggest more sophisticated mechanisms on top, addressing more use cases. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
