Hi Nikolay, On Thu, Nov 13, 2014 at 4:02 PM, Nikolay Nikolaev <n.nikolaev@xxxxxxxxxxxxxxxxxxxxxx> wrote: [...] >>>>>> >>>>>> >>>>>> We're reconsidering ioeventfds patchseries and we tried to evaluate >>>>>> what you suggested here. >>>>>> >>>>>>> >>>>>>> this special-casing of the vgic is now really terrible. Is there >>>>>>> anything holding you back from doing the necessary restructure of the >>>>>>> kvm_bus_io_*() API instead? >>>>>> >>>>>> Restructuring the kvm_io_bus_ API is not a big thing (we actually did >>>>>> it), but is not directly related to the these patches. >>>>>> Of course it can be justified if we do it in the context of removing >>>>>> vgic_handle_mmio and leaving only handle_kernel_mmio. >>>>>> >>>>>>> >>>>>>> That would allow us to get rid of the ugly >>>>>>> Fix it! in the vgic driver as well. >>>>>> >>>>>> Going through the vgic_handle_mmio we see that it will require large >>>>>> refactoring: >>>>>> - there are 15 MMIO ranges for the vgic now - each should be >>>>>> registered as a separate device >> Re-correcting Andre's address, sorry: >> Hi Nikolay, Andre, >> >> what does mandate to register 15 devices? Isn't possible to register a >> single kvm_io_device covering the whole distributor range [base, base + >> KVM_VGIC_V2_DIST_SIZE] (current code) and in associated >> kvm_io_device_ops read/write locate the addressed range and do the same >> as what is done in current vgic_handle_mmio? Isn't it done that way for > > Well, then we'll actually get slower mmio processing. Instead of calling > vgic_handle_mmio in io_mem_abort, we'll be calling kvm_io_bus_write. > This just adds another level of translation (i.e. find the kvm_io_ device) > and the underlying vgic code will remain almost the same. > Define slower please. Have you measured this? With my ideas about where we are spending overhead on a world-switch in this system, looping through a few ranges is going to be infinitesimal, but as I said, we would need to measure it before using it as an argument to structure the code in a certain way, unless of course we're obviously doing O(n^2) operations or something idiotic like that. -Christoffer -- 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
