On 22/10/14 17:12, Wei Huang wrote: > > > On 10/22/2014 10:07 AM, Marc Zyngier wrote: >> We have DT/ACPI/whatever for this exact purpose: finding out what the >> hardware is. These mechanisms give us structured information that >> describe the available HW in great detail, and I will strongly oppose >> any form of guess-work. >> >> Sorry, but I have to ask: what is wrong with the current DT parsing? > > A bit long story. DT parsing itself was not a problem until recently > when ACPI was enabled. It broke KVM because KVM doesn't support ACPI. So > we started to add ACPI parsing into KVM code (virt/kvm/arm/, see > Alexander Spyridakis' recent patches, very similar to our internal > fixes). It turned out to be quite messy due to the if-DT-else-ACPI in > arch_timer and vgic code. Additionally kernel does the parsing twice, > one in native drivers and the other in KVM, which is unnecessary. Not twice. They use different information that happen to be contained in the same nodes/tables. As for the DT-vs-ACPI ugliness, this can be resolved once we have an actual usage pattern. At the moment, I definitely want to see the ugliness, not hide it away. > My proposal is to get rid of DT-ACPI parsing in KVM completely. We rely > on device drivers to provide necessary info, which makes the interface > cleaner. arch_timer is very easy to fix (see > https://lists.cs.columbia.edu/pipermail/kvmarm/2014-October/011526.html); but > GIC is complicated because vgic.c dispatches to vgic-v2 and vgic-v3. And how do you propose to expose this all this information in a GIC-agnostic way, that will scale to GICv4 and whatever comes after that? How will that work if we ever manage to make KVM a loadable kernel module? Also, you're going to have things like gicv2_get_fimware_info() and gicv3_get_firmware_info(). You're going to have to call both, and find out which one gives you a sensible answer. I'd rather see the firmware tables being directly parsed. As for the timer change, I really dislike it. It creates yet another global interface that gets in the way of proper modularity (we already have the ugly timecounter that I'd really like to get rid off...). > My question to Andre was: could GIC drivers provides some info for KVM > to query, such as GIC version. This request in fact is to eliminate > guess work from KVM's perspective. And I have to ask back: why do you think we have firmware tables? They already contain what we need, in a standardized way. Accessing the MADT table will give you what you need. It would be a lot better if you could post your patches so we can do better than talk hypothetically. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
