On 2011-10-18 13:58, Michael S. Tsirkin wrote: > On Mon, Oct 17, 2011 at 09:28:12PM +0200, Jan Kiszka wrote: >> On 2011-10-17 17:48, Michael S. Tsirkin wrote: >>> On Mon, Oct 17, 2011 at 11:28:02AM +0200, Jan Kiszka wrote: >>>> This optimization was only required to keep KVM route usage low. Now >>>> that we solve that problem via lazy updates, we can drop the field. We >>>> still need interfaces to clear pending vectors, though (and we have to >>>> make use of them more broadly - but that's unrelated to this patch). >>>> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> >>> >>> Lazy updates should be an implementation detail. >>> IMO resource tracking of vectors makes sense >>> as an API. Making devices deal with pending >>> vectors as a concept, IMO, does not. >> >> There is really no use for tracking the vector lifecycle once we have >> lazy updates (except for static routes). It's a way too invasive >> concept, and it's not needed for anything but KVM. > > I think it's needed. The PCI spec states that when the device > does not need an interrupt anymore, it should clear the pending > bit. That should be done explicitly if it is required outside existing clearing points. We already have that service, it's called msix_clear_vector. That alone does not justify msix_vector_use and all the state and logic behind it IMHO. > The use/unuse is IMO a decent API for this, > because it uses a familiar resource tracking concept. > Exposing this knowledge of msix to devices seems > like a worse API. > >> >> If you want an example, check >> http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/70915 and >> compare it to the changes done to hpet in this series. >> >> Jan >> > > This seems to be a general argument that lazy updates are good? > I have no real problem with them, besides the fact that > we need an API to reserve space in the routing > table so that device setup can fail upfront. That's not possible, even with used vectors, as devices change their vector usage depending on how the guest configures the devices. If you (pre-)allocate all possible vectors, you may run out of resources earlier than needed actually. That's also why we do those data == 0 checks to skip used but unconfigured vectors. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
