On 07/04/2010 12:17 PM, Alexander Graf wrote:
On 04.07.2010, at 11:10, Avi Kivity wrote:
On 07/04/2010 12:04 PM, Alexander Graf wrote:
My biggest concern about putting things in the device-tree is that I was trying to keep things as separate as possible. Why does the firmware have to know that it's running in KVM?
It doesn't need to know about kvm, it needs to know that a particular hypercall protocol is available.
Considering how the parts of the draft that I read about sound like, that's not the inventor's idea. PPC people love to see the BIOS be part of the virtualization solution. I don't. That's the biggest difference here and reason for us going different directions.
Regardless of which direction is "correct", you need to go in one direction.
I think what they thought of is something like
if (in_kvm()) {
device_tree_put("/hypervisor/exit", EXIT_TYPE_MAGIC);
device_tree_put("/hypervisor/exit_magic", EXIT_MAGIC);
}
which then the OS reads out. But that's useless, as the hypercalls are hypervisor specific. So why make the detection on the Linux side generic?
Looks like the benefit is less magic in the detection code. x86 has
(more or less) standardized feature detection. Is this an attempt to
bring something similar to ppc-land?
Why do I have to patch 3 projects (Linux, OpenBIOS, Qemu) when I could go with patching a single one (Linux)?
That's not a valid argument. You patch as many projects as it takes to get it right (not that I have an opinion in this particular discussion).
If you can put code in Linux that touches 3 submaintainer's directories or one submaintainer's directory with both ending up being functionally equivalent, which way would you go?
We would do the right thing. Trivial examples include adding defines to
include/asm/processor.h or include/asm/msr-index.h, more complicated
ones are the topic for my talk in kvm forum 2010.
Yes, coordinating the acks and trees and merge windows is not as fun as
coding. Yes, it's even more difficult with separate trees. No, that's
not an excuse if we[1] determine that the right thing to do is the most
complicated.
[1] "we" in this case are the powerpc Linux arch maintainers and/or
whoever defines the hardware specification
At the very least you have to patch qemu for reasons described before (backwards compatible live migration).
There is no live migration on PPC (yet). That point is completely moot atm.
You still need to make that feature disableable from userspace.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
