Hollis Blanchard wrote: > If it's the "ioctl" in the function name you object to, that's easily > changed. >
It's not the name, it's what you're doing. You're introducing an architecture specific ioctl that essentially overrides an common-ioctl(). If anything, I would think it would be better to expand the existing common-ioctl with the notion and then have a per-architecture hook within that ioctl. > I think it's reasonable to say that single-system-image software > requires identical cores, but that's not what we're talking about here. > Heterogeneous core designs are not common, but a VM needs to reflect > hardware layout, and people do it in hardware (again, not running a > single system image). > > "VCPU type" is a VCPU property, and I think the design should reflect > that, and as you can see from the patch it's not at all difficult to do. > There are all sorts of crazy things you can do in actual hardware. Look at the way the cell processor handles memory for SPUs. You would need to change the KVM memory code to have per-CPU slots or something to support that. We shouldn't design for any possible thing that anyone could want in the future, but rather for the things that we actually can see doing. If you don't think there's a reasonable chance that you'll be attempting to implement asymmetric cores in the near future, I wouldn't think it's wise to over complicate things. Regards, Anthony Liguori ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
