On Mon, Jul 28, 2008 at 08:56:34AM +0800, Tian, Kevin wrote: > >I guess the solution for such issues is not to have kvm (or qemu) play > >with nice levels, but instead send notifications on virtual frequency > >changes on the qemu monitor. The management application can then choose > >whether to ignore the information, play with nice levels, or even > >propagate the frequency change to the host (useful in client-side > >virtualization).
I like this idea too. I've been giving a little more thought to how we present cpufreq "control" to the guest. According to the ACPI specs, either we can implement a fixed hardware implementation (i.e. MSRs) or we can provide a system i/o address that (presumably) traps to the firmware so that the BIOS can do the actual work. Since the MSRs controls are different between Intel and AMD (Linux refuses to use Intel MSRs on an AMD CPU and vice versa), I'm thinking it might be easier to use the system I/O route because then we don't have to spend any code emulating the hardware mechanisms when we don't need to do so. Of course, that's assuming that it's easy to set up a "magic" I/O port on the guest that will trap into the VMM so that we can perform whatever magic we want. I would assume that this is the case, though I've only just now gotten back to this patch set. I've also not studied the speed difference between the emulated wrmsr command and this manner of I/O port access, but I suppose I can try it and find out. :) At least in theory this would also eliminate an obstacle to migrating VMs from Intel to AMD CPUs, but I suspect that's not really feasible anyway. --D -- 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
