From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Alexander Graf <agraf@suse.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
Paul Mackerras <paulus@samba.org>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH] powerpc iommu: enable multiple TCE requests
Date: Tue, 20 Aug 2013 11:09:06 +0200 [thread overview]
Message-ID: <52133232.7010809@redhat.com> (raw)
In-Reply-To: <52132D9F.8070607@ozlabs.ru>
Il 20/08/2013 10:49, Alexey Kardashevskiy ha scritto:
> On 08/20/2013 06:39 PM, Paolo Bonzini wrote:
>> Il 20/08/2013 03:36, Alexey Kardashevskiy ha scritto:
>>> Hm. Here we might have a problem like this is we decide to migrate from
>>> QEMU with this patch running on modern kernel to QEMU without this patch
>>> running on old kernel - for this we might want to be able to disable
>>> "multi-tce" via machine options on newer kernels. Do we care enough to add
>>> such a parameter or we just disable migration and that's it?
>>
>> Upstream doesn't support migration to older QEMU.
>
> Hm. That makes things simpler. Then I do not understand why we need
> migration protocol versions as QEMU version in stronger version for
> migration. Ah, offtopic.
Because you have multiple downstreams that can backport arbitrary crap
on top of the same base QEMU version.
In RHEL for example we do some effort to force usage of older version
IDs (or to forcibly leave out subsections) depending on the machine type
you're using.
So even though upstream is limited in the kind of migrations we support,
we provide the infrastructure for downstreams to give stronger guarantees.
>>> This SandyBridge,enforce - what if the destination host running on old
>>> kernel was run without this option - will the migration fail?
>>
>> The destination machine will not even start.
>>
>>>> But in this case, you do not need this because the hypercall works if
>>>> emulated by QEMU. I like Alex's solution of making it universally
>>>> available in the dtb.
>>>
>>> The solution would be good if we did not already have H_PUT_TCE accelerated
>>> for emulated devices in the host kernel but we do have it.
>>
>> The question is also whether you consider pSeries support complete
>> enough to be production ready---and until you have versioned machine
>> types I would say you don't.
>>
>> If you still consider it somewhat experimental, I would do as Alex said:
>> make newer QEMU on older KVM as slower, and that's it.
>
> Sorry if I miss anything, but is not it what the patch already does? :)
No, you need to expose multitce unconditionally in the device tree.
Paolo
> If so, I'll repost this patch + traces rework tomorrow or so.
next prev parent reply other threads:[~2013-08-20 9:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-07 8:08 [Qemu-devel] [PATCH] powerpc iommu: enable multiple TCE requests Alexey Kardashevskiy
2013-08-16 9:49 ` Alexey Kardashevskiy
2013-08-18 15:22 ` Paolo Bonzini
2013-08-19 7:30 ` Alexey Kardashevskiy
2013-08-19 8:01 ` Alexander Graf
2013-08-19 8:44 ` Alexey Kardashevskiy
2013-08-19 9:47 ` Paolo Bonzini
2013-08-20 1:36 ` Alexey Kardashevskiy
2013-08-20 6:55 ` Alexander Graf
2013-08-20 8:39 ` Paolo Bonzini
2013-08-20 8:49 ` Alexey Kardashevskiy
2013-08-20 9:09 ` Paolo Bonzini [this message]
2013-08-20 9:13 ` Benjamin Herrenschmidt
2013-08-20 9:15 ` Paolo Bonzini
2013-08-20 9:20 ` Benjamin Herrenschmidt
2013-08-20 9:22 ` Paolo Bonzini
2013-08-20 9:26 ` Benjamin Herrenschmidt
2013-08-20 10:14 ` Paolo Bonzini
2013-08-20 11:38 ` Benjamin Herrenschmidt
2013-08-21 7:11 ` Alexander Graf
2013-08-21 7:29 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2013-08-16 13:15 ` [Qemu-devel] " Alexander Graf
2013-08-19 9:01 ` Alexey Kardashevskiy
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=52133232.7010809@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=david@gibson.dropbear.id.au \
--cc=paulus@samba.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.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).