On Mon, 15 Dec 2014, Ted Unangst wrote: > On Mon, Dec 15, 2014 at 23:55, Stefan Fritsch wrote: > > > > Only in order to get a flags field that can be tweaked with config(8). And > > to allow disable via config(8), though that could also be achieved with a > > flag. > > > > Tweaking the behavior with a flags value is necessary because hypervisors > > not always announce what they are capable of. One reason for this is that > > qemu is responsible for setting most of the cpuid flags but the kvm kernel > > module offers some interfaces in all cases. Another reason seems to be > > simple oversight, for example Illuminos KVM forgot to add the cpuid stuff > > from Linux KVM. And if there is some bug it may be a good idea to have a > > simple way to check if it is related to the paravirt stuff. > > > > I have just noticed that there is support in config(8) to set non-devices > > related int values. But this does not seem to be supported in the > > in-kernel UKC. And I can't see right now how config finds the valid int > > values in the kernel. Or is it just necessary to add the name of the > > variable prepended by an underscore to the config tool? Would this be > > preferred over introducing the paravirt device? But being able to set this > > from the in-kernel UKC would be nice, too.
What I have forgotten is that just because a hypervisor supports a specific interface, it does not always mean that it is a good idea to use it. For example, recent Intel CPUs with a recent Linux/KVM have better hardware support for APIC virtualization and using the Hyper-V APIC access MSRs actually slow things down. > I think it would be better to avoid fake device proliferation, but > others may have other opinions. > > So the problem is that some hypervisors are "broken" and don't > identify as such? Perhaps we ignore them to start? Then we can add a > mechanism to force paravirt code patching. > > I think the introduction of paravirt code patching and the mechanism > used to enable or disable are separate issues. It can start as a > normal option PARAVIRT, and then we discuss what else needs to be done? Yes, we can first start with some things that are unproblematic WRT detection. AFAIK, this is the case for the PV EOI optimization. Unfortunately, the bit that gives the largest performance boost at the moment, the APIC access MSRs, is not so easy: - KVM has supported it for a long time - but it is only announced if qemu is started with a special command line option - Illumos KVM supports it too, but there is no way to announce it Also, old hypervisors tend to stay around for a long time and users can't always influence the configuration when they rent a vserver. On the other hand, the same positive effect as the APIC access MSRs should also be achievable by adding x2apic support. kettenis wanted to check how much effort that would be. So, I think it would be best to wait a bit with this piece.
