On 20.08.2013, at 12:38, Benjamin Herrenschmidt wrote:
> On Tue, 2013-08-20 at 12:14 +0200, Paolo Bonzini wrote:
>>> I suppose if RH is going to deploy 3.10 and we aren't going to backport
>>> the multitce patches then there *might* be a case for supporting that
>>> combo specifically... but it's
On Tue, 2013-08-20 at 12:14 +0200, Paolo Bonzini wrote:
> > I suppose if RH is going to deploy 3.10 and we aren't going to backport
> > the multitce patches then there *might* be a case for supporting that
> > combo specifically... but it's going to be that bad every time we add
> > a new feature w
Il 20/08/2013 11:26, Benjamin Herrenschmidt ha scritto:
> On Tue, 2013-08-20 at 11:22 +0200, Paolo Bonzini wrote:
>>
>> Uhm... I thought Alex and I were the one who proposed the simple things.
>> You _will_ need to do the complicated stuff sooner or later, but it's
>> probably early enough now to
On Tue, 2013-08-20 at 11:22 +0200, Paolo Bonzini wrote:
>
> Uhm... I thought Alex and I were the one who proposed the simple things.
> You _will_ need to do the complicated stuff sooner or later, but it's
> probably early enough now to ignore it.
>
> And I'm not saying this out of love for big c
Il 20/08/2013 11:20, Benjamin Herrenschmidt ha scritto:
> On Tue, 2013-08-20 at 11:15 +0200, Paolo Bonzini wrote:
>>
>> - provide the infrastructure to enable/disable it from the command
>> line
>> (which will be enough design effort alone);
>
> ... why do things simply when we can come up with a
On Tue, 2013-08-20 at 11:15 +0200, Paolo Bonzini wrote:
>
> - provide the infrastructure to enable/disable it from the command
> line
> (which will be enough design effort alone);
... why do things simply when we can come up with a cathedral
instead ?
> - add pseries-1.6 as a synonym of pseries
Il 20/08/2013 11:13, Benjamin Herrenschmidt ha scritto:
> On Tue, 2013-08-20 at 11:09 +0200, Paolo Bonzini wrote:
>>> 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.
>
> If I'm not mistaken the mul
On Tue, 2013-08-20 at 11:09 +0200, Paolo Bonzini wrote:
> > 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.
If I'm not mistaken the multitce kernel side patches are still not
upstream so I disagree.
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
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 wa
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
On 20.08.2013, at 02:36, Alexey Kardashevskiy wrote:
> On 08/19/2013 07:47 PM, Paolo Bonzini wrote:
>> Il 19/08/2013 10:44, Alexey Kardashevskiy ha scritto:
> It means that if you use the same QEMU version with the same command
> line on a different kernel version, your guest looks differ
On 08/19/2013 07:47 PM, Paolo Bonzini wrote:
> Il 19/08/2013 10:44, Alexey Kardashevskiy ha scritto:
It means that if you use the same QEMU version with the same command
line on a different kernel version, your guest looks different because
we generate the dtb differently.
>> Oh. Sor
Il 19/08/2013 10:44, Alexey Kardashevskiy ha scritto:
>> > It means that if you use the same QEMU version with the same command
>> > line on a different kernel version, your guest looks different because
>> > we generate the dtb differently.
> Oh. Sorry for my ignorance again, I am not playing dump
On 08/16/2013 11:15 PM, Alexander Graf wrote:
>
> On 07.08.2013, at 10:08, Alexey Kardashevskiy wrote:
>
>> Currently only single TCE entry per requiest is supported (H_PUT_TCE).
>> However PAPR+ specification allows multiple entry requests such as
>> H_PUT_TCE_INDIRECT and H_STUFFF_TCE. Having l
On 08/19/2013 06:01 PM, Alexander Graf wrote:
>
>
> Am 19.08.2013 um 09:30 schrieb Alexey Kardashevskiy :
>
>> On 08/19/2013 01:22 AM, Paolo Bonzini wrote:
>>> Il 16/08/2013 11:49, Alexey Kardashevskiy ha scritto:
With KVM, we could fall back to the qemu implementation
> + * when KV
Am 19.08.2013 um 09:30 schrieb Alexey Kardashevskiy :
> On 08/19/2013 01:22 AM, Paolo Bonzini wrote:
>> Il 16/08/2013 11:49, Alexey Kardashevskiy ha scritto:
>>> With KVM, we could fall back to the qemu implementation
+ * when KVM doesn't support them, but that would be much slower
On 08/19/2013 01:22 AM, Paolo Bonzini wrote:
> Il 16/08/2013 11:49, Alexey Kardashevskiy ha scritto:
>> With KVM, we could fall back to the qemu implementation
>>> + * when KVM doesn't support them, but that would be much slower
>>> + * than just using the KVM implementations of the single
Il 16/08/2013 11:49, Alexey Kardashevskiy ha scritto:
> With KVM, we could fall back to the qemu implementation
>> + * when KVM doesn't support them, but that would be much slower
>> + * than just using the KVM implementations of the single TCE
>> + * hypercalls. */
>> +if (kvmppc_s
On 07.08.2013, at 10:08, Alexey Kardashevskiy wrote:
> Currently only single TCE entry per requiest is supported (H_PUT_TCE).
> However PAPR+ specification allows multiple entry requests such as
> H_PUT_TCE_INDIRECT and H_STUFFF_TCE. Having less transitions to the host
> kernel via ioctls, suppor
On 08/07/2013 06:08 PM, Alexey Kardashevskiy wrote:
> Currently only single TCE entry per requiest is supported (H_PUT_TCE).
> However PAPR+ specification allows multiple entry requests such as
> H_PUT_TCE_INDIRECT and H_STUFFF_TCE. Having less transitions to the host
> kernel via ioctls, support o
Currently only single TCE entry per requiest is supported (H_PUT_TCE).
However PAPR+ specification allows multiple entry requests such as
H_PUT_TCE_INDIRECT and H_STUFFF_TCE. Having less transitions to the host
kernel via ioctls, support of these calls can accelerate IOMMU operations.
This also re
22 matches
Mail list logo
