Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux