On Wed, Aug 08, 2012 at 05:22:11PM +0200, Andreas Färber wrote:
> Am 08.08.2012 03:45, schrieb David Gibson:
> > On Wed, Aug 08, 2012 at 12:32:39AM +0200, Andreas Färber wrote:
> >> Am 08.08.2012 00:02, schrieb Benjamin Herrenschmidt:
> >>> On Fri, 2012-08-03 at 17:01 +0200, Andreas Färber wrote:
>
Am 08.08.2012 03:45, schrieb David Gibson:
> On Wed, Aug 08, 2012 at 12:32:39AM +0200, Andreas Färber wrote:
>> Am 08.08.2012 00:02, schrieb Benjamin Herrenschmidt:
>>> On Fri, 2012-08-03 at 17:01 +0200, Andreas Färber wrote:
I have posted a suggestion where CPU reset is triggered by "the
On Wed, Aug 08, 2012 at 08:58:07AM +0100, Peter Maydell wrote:
> On 8 August 2012 01:00, Anthony Liguori wrote:
> >
> > They need a per machine hook before and after devices are created. This is
> > okay and it turns out it can be handy for other machines too that do
> > similiar could not exist
On 8 August 2012 01:00, Anthony Liguori wrote:
>
> They need a per machine hook before and after devices are created. This is
> okay and it turns out it can be handy for other machines too that do
> similiar could not exist outside of a simulator features.
If it's 'before and after device creati
On Wed, Aug 08, 2012 at 12:32:39AM +0200, Andreas Färber wrote:
> Am 08.08.2012 00:02, schrieb Benjamin Herrenschmidt:
> > On Fri, 2012-08-03 at 17:01 +0200, Andreas Färber wrote:
> >>
> >> I have posted a suggestion where CPU reset is triggered by "the
> >> machine
> >> as an abstract concept" (ne
On Aug 7, 2012 5:32 PM, "Andreas Färber" wrote:
>
> Am 08.08.2012 00:02, schrieb Benjamin Herrenschmidt:
> > On Fri, 2012-08-03 at 17:01 +0200, Andreas Färber wrote:
> >>
> >> I have posted a suggestion where CPU reset is triggered by "the
> >> machine
> >> as an abstract concept" (needs a bit of
Am 08.08.2012 00:02, schrieb Benjamin Herrenschmidt:
> On Fri, 2012-08-03 at 17:01 +0200, Andreas Färber wrote:
>>
>> I have posted a suggestion where CPU reset is triggered by "the
>> machine
>> as an abstract concept" (needs a bit of tweaking still, but the
>> general
>> idea is there).
>> Based
On Fri, 2012-08-03 at 17:01 +0200, Andreas Färber wrote:
>
> I have posted a suggestion where CPU reset is triggered by "the
> machine
> as an abstract concept" (needs a bit of tweaking still, but the
> general
> idea is there).
> Based on that, shouldn't it be rather easy to add a Notifier simila
On Fri, Aug 03, 2012 at 05:13:48PM +0200, Andreas Färber wrote:
> Am 03.08.2012 04:31, schrieb David Gibson:
> > On Thu, Aug 02, 2012 at 05:44:49PM +0200, Andreas Färber wrote:
> >> Am 02.08.2012 04:10, schrieb David Gibson:
[snip]
> >>> -static void spapr_cpu_reset(void *opaque)
> >>> -{
> >>> -
Andreas Färber writes:
> Am 02.08.2012 21:40, schrieb Anthony Liguori:
>> Reset propagates. There is unanimous consensus that this is the Right
>> Way to model reset. There is also wide consensus that reset typically
>> will propagate through the composition tree although in some cases,
>> rese
Am 03.08.2012 04:31, schrieb David Gibson:
> On Thu, Aug 02, 2012 at 05:44:49PM +0200, Andreas Färber wrote:
>> Am 02.08.2012 04:10, schrieb David Gibson:
>>> A number of things need to occur during reset of the PAPR paravirtualized
>>> platform in a specific order. For example, the hash table nee
Am 02.08.2012 21:40, schrieb Anthony Liguori:
> Reset propagates. There is unanimous consensus that this is the Right
> Way to model reset. There is also wide consensus that reset typically
> will propagate through the composition tree although in some cases,
> reset actually propagates through t
Am 02.08.2012 21:40, schrieb Anthony Liguori:
> Andreas Färber writes:
>
>> Am 02.08.2012 20:29, schrieb Anthony Liguori:
>>> Andreas Färber writes:
>>>
Anthony was favoring moving reset code out of machines and expressed
dislike for looping through CPUs, which my above patch took into
On 3 August 2012 15:22, Anthony Liguori wrote:
> Peter Maydell writes:
>> On 3 August 2012 14:50, Anthony Liguori wrote:
>>> There ought to be a hierarchy (based on composition) that reset flows
>>> through.
>>
>> I think saying "the reset tree is isomorphic to the composition tree"
>> is making
Peter Maydell writes:
> On 3 August 2012 14:50, Anthony Liguori wrote:
>> There ought to be a hierarchy (based on composition) that reset flows
>> through.
>
> I think saying "the reset tree is isomorphic to the composition tree"
> is making the same mistake that qbus did with "the bus tree is
>
On 3 August 2012 14:50, Anthony Liguori wrote:
> There ought to be a hierarchy (based on composition) that reset flows
> through.
I think saying "the reset tree is isomorphic to the composition tree"
is making the same mistake that qbus did with "the bus tree is
isomorphic to the composition tree
David Gibson writes:
> On Thu, Aug 02, 2012 at 02:40:19PM -0500, Anthony Liguori wrote:
>> The "root" of the composition tree is the machine. The machine in the
>> abstract sense, not the QEMUMachine sense. QEMUMachine::init() should
>> eventually become trivial--just create a handful of device
On Thu, Aug 02, 2012 at 02:40:19PM -0500, Anthony Liguori wrote:
> Andreas Färber writes:
>
> > Am 02.08.2012 20:29, schrieb Anthony Liguori:
> >> Andreas Färber writes:
> >>
> >>> Anthony was favoring moving reset code out of machines and expressed
> >>> dislike for looping through CPUs, which
On Thu, Aug 02, 2012 at 05:44:49PM +0200, Andreas Färber wrote:
> Am 02.08.2012 04:10, schrieb David Gibson:
> > A number of things need to occur during reset of the PAPR paravirtualized
> > platform in a specific order. For example, the hash table needs to be
> > cleared before the CPUs are reset
Andreas Färber writes:
> Am 02.08.2012 20:29, schrieb Anthony Liguori:
>> Andreas Färber writes:
>>
>>> Anthony was favoring moving reset code out of machines and expressed
>>> dislike for looping through CPUs, which my above patch took into
>>> account. The ordering issue between CPU and devic
Am 02.08.2012 20:29, schrieb Anthony Liguori:
> Andreas Färber writes:
>
>> Anthony was favoring moving reset code out of machines and expressed
>> dislike for looping through CPUs, which my above patch took into
>> account. The ordering issue between CPU and devices is still unsolved there.
>>
>
Andreas Färber writes:
> Am 02.08.2012 04:10, schrieb David Gibson:
>> A number of things need to occur during reset of the PAPR paravirtualized
>> platform in a specific order. For example, the hash table needs to be
>> cleared before the CPUs are reset, so that they initialize their register
>
Am 02.08.2012 04:10, schrieb David Gibson:
> A number of things need to occur during reset of the PAPR paravirtualized
> platform in a specific order. For example, the hash table needs to be
> cleared before the CPUs are reset, so that they initialize their register
> state correctly, and the CPUs
23 matches
Mail list logo
