On Mon, 2014-04-14 at 21:14 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2014-04-14 at 17:12 +1000, Alexey Kardashevskiy wrote:
> > Our additional PHBs require @index property which is used to calculate
> > base
> > MMIO and IO ranges. That we could use for LSI/MSI too.
>
> That works. We need t
On Mon, 2014-04-14 at 17:12 +1000, Alexey Kardashevskiy wrote:
> Our additional PHBs require @index property which is used to calculate
> base
> MMIO and IO ranges. That we could use for LSI/MSI too.
That works. We need to decide how much interrupt "space" we give to
each.
The HW on P8 does 2048
On Mon, 2014-04-14 at 08:37 +0200, Alexander Graf wrote:
> So we either have to create some way to make interrupt numbering a
> function of something very simple we plug the PHB into, like a virtual
> pseries slot number which we multiply by x to get an irq number range.
> Or we'd have to manual
On Mon, 2014-04-14 at 08:32 +0200, Alexander Graf wrote:
> So for chips that might be configurable, configuration has to happen via
> some SPR, right? Wouldn't it make sense to transfer that configuration
> SPR on these and thus the configuration as well?
Well, on a real 970 I can always go poke
On 14.04.14 09:12, Alexey Kardashevskiy wrote:
On 04/14/2014 04:37 PM, Alexander Graf wrote:
On 12.04.14 23:44, Benjamin Herrenschmidt wrote:
On Sat, 2014-04-12 at 16:31 +0200, Alexander Graf wrote:
Don't we generate PHBs on the fly? How exactly is this going to help
with the problem at hand?
On 04/14/2014 04:37 PM, Alexander Graf wrote:
>
> On 12.04.14 23:44, Benjamin Herrenschmidt wrote:
>> On Sat, 2014-04-12 at 16:31 +0200, Alexander Graf wrote:
>>> Don't we generate PHBs on the fly? How exactly is this going to help
>>> with the problem at hand?
>> We can still assign the interrupt
On 12.04.14 23:44, Benjamin Herrenschmidt wrote:
On Sat, 2014-04-12 at 16:31 +0200, Alexander Graf wrote:
Don't we generate PHBs on the fly? How exactly is this going to help
with the problem at hand?
We can still assign the interrupts as a fixed function of the PHB
number...
Yes, but we cre
On 12.04.14 17:51, Alexey Kardashevskiy wrote:
On 04/11/2014 07:40 PM, Alexander Graf wrote:
On 10.04.14 16:31, Alexey Kardashevskiy wrote:
On 04/10/2014 10:34 PM, Alexander Graf wrote:
On 03.04.14 15:14, Alexey Kardashevskiy wrote:
This allows guests to have a different timebase origin from
On 13.04.14 07:56, Benjamin Herrenschmidt wrote:
On Sun, 2014-04-13 at 00:38 +0100, Peter Maydell wrote:
From a design standpoint I find that totally retarded btw :-)
I agree it's bonkers; it's just that fixing it requires a big pile
of design and implementation work from somebody; and in
the
On Sun, 2014-04-13 at 00:38 +0100, Peter Maydell wrote:
> > From a design standpoint I find that totally retarded btw :-)
>
> I agree it's bonkers; it's just that fixing it requires a big pile
> of design and implementation work from somebody; and in
> the meantime "both ends must be configured id
On 12 April 2014 11:31, Benjamin Herrenschmidt wrote:
> On Sat, 2014-04-12 at 09:25 +0200, Alexander Graf wrote:
>> Exactly. We should try to migrate only state that the user doesn't
>> specify on the command line.
>
> From a design standpoint I find that totally retarded btw :-)
I agree it's bon
On Sat, 2014-04-12 at 16:31 +0200, Alexander Graf wrote:
> Don't we generate PHBs on the fly? How exactly is this going to help
> with the problem at hand?
We can still assign the interrupts as a fixed function of the PHB
number...
Cheers,
Ben.
On 04/11/2014 07:40 PM, Alexander Graf wrote:
>
> On 10.04.14 16:31, Alexey Kardashevskiy wrote:
>> On 04/10/2014 10:34 PM, Alexander Graf wrote:
>>> On 03.04.14 15:14, Alexey Kardashevskiy wrote:
This allows guests to have a different timebase origin from the host.
This is needed f
> Am 12.04.2014 um 12:31 schrieb Benjamin Herrenschmidt
> :
>
>> On Sat, 2014-04-12 at 09:25 +0200, Alexander Graf wrote:
>> Exactly. We should try to migrate only state that the user doesn't
>> specify on the command line.
>
> From a design standpoint I find that totally retarded btw :-)
>
>
On Sat, 2014-04-12 at 09:25 +0200, Alexander Graf wrote:
> Exactly. We should try to migrate only state that the user doesn't
> specify on the command line.
>From a design standpoint I find that totally retarded btw :-)
The sensible thing to do would have been for the configuration to
migrate alo
> Am 12.04.2014 um 05:44 schrieb Alexey Kardashevskiy :
>
>> On 04/12/2014 07:55 AM, Benjamin Herrenschmidt wrote:
>> On Fri, 2014-04-11 at 11:40 +0200, Alexander Graf wrote:
And G5 uses . I really do not understand why it is bad to
send-and-check timer frequency. Why?
>>>
>>>
On 04/12/2014 07:55 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2014-04-11 at 11:40 +0200, Alexander Graf wrote:
>>> And G5 uses . I really do not understand why it is bad to
>>> send-and-check timer frequency. Why?
>>
>> Because the guest will continue to run at a different TB frequency on
> Am 11.04.2014 um 23:55 schrieb Benjamin Herrenschmidt
> :
>
> On Fri, 2014-04-11 at 11:40 +0200, Alexander Graf wrote:
>>> And G5 uses . I really do not understand why it is bad to
>>> send-and-check timer frequency. Why?
>>
>> Because the guest will continue to run at a different TB
On Fri, 2014-04-11 at 11:40 +0200, Alexander Graf wrote:
> > And G5 uses . I really do not understand why it is bad to
> > send-and-check timer frequency. Why?
>
> Because the guest will continue to run at a different TB frequency on
> the new host and break.
Right, which is why we shoul
On 10.04.14 16:31, Alexey Kardashevskiy wrote:
On 04/10/2014 10:34 PM, Alexander Graf wrote:
On 03.04.14 15:14, Alexey Kardashevskiy wrote:
This allows guests to have a different timebase origin from the host.
This is needed for migration, where a guest can migrate from one host
to another an
On 04/10/2014 10:34 PM, Alexander Graf wrote:
>
> On 03.04.14 15:14, Alexey Kardashevskiy wrote:
>> This allows guests to have a different timebase origin from the host.
>>
>> This is needed for migration, where a guest can migrate from one host
>> to another and the two hosts might have a differe
On 03.04.14 15:14, Alexey Kardashevskiy wrote:
This allows guests to have a different timebase origin from the host.
This is needed for migration, where a guest can migrate from one host
to another and the two hosts might have a different timebase origin.
However, the timebase seen by the guest
This allows guests to have a different timebase origin from the host.
This is needed for migration, where a guest can migrate from one host
to another and the two hosts might have a different timebase origin.
However, the timebase seen by the guest must not go backwards, and
should go forwards onl
23 matches
Mail list logo
