On 07/04/2010 12:17 PM, Alexander Graf wrote:
quoted text
> 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.

quoted text
> 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?

quoted text
>>> 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

quoted text
>> 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" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html