From: Avi Kivity <avi@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: kvm-ppc@vger.kernel.org,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
KVM list <kvm@vger.kernel.org>
Subject: Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
Date: Sun, 04 Jul 2010 12:37:33 +0300 [thread overview]
Message-ID: <4C30565D.6030508@redhat.com> (raw)
In-Reply-To: <40488555-C73E-4C04-BFAD-31ED99CDBBDA@suse.de>
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
next prev parent reply other threads:[~2010-07-04 9:37 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-01 10:42 [PATCH 00/27] KVM PPC PV framework Alexander Graf
2010-07-01 10:42 ` [PATCH 01/27] KVM: PPC: Introduce shared page Alexander Graf
2010-07-01 10:42 ` [PATCH 02/27] KVM: PPC: Convert MSR to " Alexander Graf
2010-07-01 10:42 ` [PATCH 03/27] KVM: PPC: Convert DSISR " Alexander Graf
2010-07-01 10:42 ` [PATCH 04/27] KVM: PPC: Convert DAR " Alexander Graf
2010-07-01 10:42 ` [PATCH 05/27] KVM: PPC: Convert SRR0 and SRR1 " Alexander Graf
2010-07-01 10:42 ` [PATCH 06/27] KVM: PPC: Convert SPRG[0-4] " Alexander Graf
2010-07-01 10:42 ` [PATCH 07/27] KVM: PPC: Implement hypervisor interface Alexander Graf
2010-07-01 10:42 ` [PATCH 08/27] KVM: PPC: Add PV guest critical sections Alexander Graf
2010-07-01 10:42 ` [PATCH 09/27] KVM: PPC: Add PV guest scratch registers Alexander Graf
2010-07-01 10:42 ` [PATCH 10/27] KVM: PPC: Tell guest about pending interrupts Alexander Graf
2010-07-01 10:42 ` [PATCH 11/27] KVM: PPC: Make RMO a define Alexander Graf
2010-07-02 16:23 ` Segher Boessenkool
2010-07-01 10:42 ` [PATCH 12/27] KVM: PPC: First magic page steps Alexander Graf
2010-07-01 10:42 ` [PATCH 13/27] KVM: PPC: Magic Page Book3s support Alexander Graf
2010-07-02 15:37 ` Alexander Graf
2010-07-04 9:42 ` Avi Kivity
2010-07-01 10:42 ` [PATCH 14/27] KVM: PPC: Magic Page BookE support Alexander Graf
2010-07-01 11:18 ` Josh Boyer
2010-07-01 12:25 ` Alexander Graf
2010-07-12 11:24 ` Liu Yu-B13201
2010-07-01 10:42 ` [PATCH 15/27] KVM: PPC: Expose magic page support to guest Alexander Graf
2010-07-01 10:42 ` [PATCH 16/27] KVM: Move kvm_guest_init out of generic code Alexander Graf
2010-07-02 7:41 ` Geert Uytterhoeven
2010-07-02 7:44 ` Alexander Graf
2010-07-01 10:42 ` [PATCH 17/27] KVM: PPC: Generic KVM PV guest support Alexander Graf
2010-07-01 10:42 ` [PATCH 18/27] KVM: PPC: KVM PV guest stubs Alexander Graf
2010-07-01 10:42 ` [PATCH 19/27] KVM: PPC: PV instructions to loads and stores Alexander Graf
2010-07-01 10:42 ` [PATCH 20/27] KVM: PPC: PV tlbsync to nop Alexander Graf
2010-07-01 10:42 ` [PATCH 21/27] KVM: PPC: Introduce kvm_tmp framework Alexander Graf
2010-07-01 10:42 ` [PATCH 22/27] KVM: PPC: Introduce branch patching helper Alexander Graf
2010-07-01 10:42 ` [PATCH 23/27] KVM: PPC: PV assembler helpers Alexander Graf
2010-07-01 10:42 ` [PATCH 24/27] KVM: PPC: PV mtmsrd L=1 Alexander Graf
2010-07-01 10:43 ` [PATCH 25/27] KVM: PPC: PV mtmsrd L=0 and mtmsr Alexander Graf
2010-07-01 10:43 ` [PATCH 26/27] KVM: PPC: PV wrteei Alexander Graf
2010-07-01 10:43 ` [PATCH 27/27] KVM: PPC: Add Documentation about PV interface Alexander Graf
2010-07-02 16:27 ` Segher Boessenkool
2010-07-02 18:41 ` Alexander Graf
2010-07-03 22:42 ` Benjamin Herrenschmidt
2010-07-04 9:04 ` Alexander Graf
2010-07-03 22:41 ` Benjamin Herrenschmidt
2010-07-04 9:04 ` Alexander Graf
2010-07-04 9:10 ` Avi Kivity
2010-07-04 9:17 ` Alexander Graf
2010-07-04 9:30 ` Alexander Graf
2010-07-04 9:41 ` Avi Kivity
2010-07-04 9:37 ` Avi Kivity [this message]
2010-07-02 17:59 ` Hollis Blanchard
2010-07-02 18:47 ` Alexander Graf
2010-07-02 19:10 ` Scott Wood
2010-07-04 9:02 ` Alexander Graf
2010-07-09 9:11 ` MJ embd
2010-07-09 9:15 ` Alexander Graf
2010-07-02 16:22 ` [PATCH 00/27] KVM PPC PV framework Segher Boessenkool
2010-07-02 16:59 ` Alexander Graf
2010-07-09 4:57 ` MJ embd
2010-07-09 6:33 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C30565D.6030508@redhat.com \
--to=avi@redhat.com \
--cc=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).