Tian, Kevin wrote: >> From:Avi Kivity >> Sent: 2008年9月27日 17:50 >> >> Yang, Sheng wrote: >>> After check host shared interrupts situation, I got a >>> question here: >>> >>> If I understand correctly, current solution don't block >>> host shared irq, just come with the performance pentry. >>> The penalty come with host disabled irq line for a >>> period. We have to wait guest to write EOI. But I fail >>> to see the correctness problem here (except a lot of >>> spurious interrupt in the guest). >>> >>> I've checked mail, but can't find clue about that. Can >>> you explain the situation? >>> >>> >> >> If the guest fails to disable interrupts on a device >> that shares an interrupt line with the host, the host >> will experience an interrupt flood. Eventually the host >> will disable the host device as well. >> > > This issue also exists on host side, that one misbehaved > driver can hurt all other drivers sharing same irq line. > But it seems no good way to avoid it. Since not all > devices support MSI, we still need support irq sharing > possibly with above caveats given. > > Existing approach at least works with a sane guest > driver, with some performance penality there. > > Or do you have better alternative? > > Thanks, > Kevin >
MSI is always 1st choice. Including taking host MSI for guest IOAPIC situation because we don't if guest OS has MSI support but we are sure host Linux can. When MSI is impossible, I recommend we disable device assignment for those sharing interrupt , or we assign all devices with same interrupt to same guest. Yes the issue is same in native, but in native the whole OS (kernel) is in same isolation domain, but now different guest has different isolation domain :( In one world, MSI is pretty important for direct IO, and SR-IOV is #1 usage in future. Just advocate more and wish more people can ack the SR-IOV patch from ZhaoYU so that we can see 2.6,28 work for direct I/O without sacrificing sharing :) Eddie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
