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.
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?
>
>> 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?
>
> 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.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
