On Tue, Jun 30, 2015 at 11:55:59AM +0100, Peter Maydell wrote:
> On 30 June 2015 at 11:50, Zhu Guihua wrote:
> > Originally, there are some devices (such as hpet, rtc) reset before apic
> > reset.
> > When these devices reset, they would send irq to apic.
>
> In our current (arguably broken) rese
On Tue, Jun 30, 2015 at 12:24:22PM +0200, Andreas Färber wrote:
> Am 30.06.2015 um 08:31 schrieb Zhu Guihua:
> > On 06/26/2015 01:28 AM, Andreas Färber wrote:
> >> Am 25.06.2015 um 19:00 schrieb Paolo Bonzini:
> >>> On 25/06/2015 04:17, Zhu Guihua wrote:
> Add a wrapper to specify reset order
On 30 June 2015 at 11:50, Zhu Guihua wrote:
> Originally, there are some devices (such as hpet, rtc) reset before apic
> reset.
> When these devices reset, they would send irq to apic.
In our current (arguably broken) reset design, this is a bug in
those devices -- they shouldn't be raising inter
On 06/30/2015 05:21 PM, Igor Mammedov wrote:
On Tue, 30 Jun 2015 14:31:50 +0800
Zhu Guihua wrote:
On 06/26/2015 01:28 AM, Andreas Färber wrote:
Am 25.06.2015 um 19:00 schrieb Paolo Bonzini:
On 25/06/2015 04:17, Zhu Guihua wrote:
Add a wrapper to specify reset order when registering reset h
Am 30.06.2015 um 08:31 schrieb Zhu Guihua:
> On 06/26/2015 01:28 AM, Andreas Färber wrote:
>> Am 25.06.2015 um 19:00 schrieb Paolo Bonzini:
>>> On 25/06/2015 04:17, Zhu Guihua wrote:
Add a wrapper to specify reset order when registering reset handler,
instead of non-obvious initiazation c
On Tue, 30 Jun 2015 14:31:50 +0800
Zhu Guihua wrote:
>
> On 06/26/2015 01:28 AM, Andreas Färber wrote:
> > Am 25.06.2015 um 19:00 schrieb Paolo Bonzini:
> >> On 25/06/2015 04:17, Zhu Guihua wrote:
> >>> Add a wrapper to specify reset order when registering reset handler,
> >>> instead of non-obv
On 06/26/2015 01:28 AM, Andreas Färber wrote:
Am 25.06.2015 um 19:00 schrieb Paolo Bonzini:
On 25/06/2015 04:17, Zhu Guihua wrote:
Add a wrapper to specify reset order when registering reset handler,
instead of non-obvious initiazation code ordering.
Signed-off-by: Zhu Guihua
I'm sorry, thi
On 26/06/2015 11:19, Igor Mammedov wrote:
> That's one of the reasons, I've asked to get rid of icc-bus.
>
> Another reason is to move default APIC MMIO mapping to CPU from board
> and handle region remapping from CPU itself as it's supposed to be if CPU
> would program another APIC base.
>
> P
On Thu, 25 Jun 2015 19:28:51 +0200
Andreas Färber wrote:
> Am 25.06.2015 um 19:00 schrieb Paolo Bonzini:
> > On 25/06/2015 04:17, Zhu Guihua wrote:
> >> Add a wrapper to specify reset order when registering reset handler,
> >> instead of non-obvious initiazation code ordering.
> >>
> >> Signed-of
Am 25.06.2015 um 19:00 schrieb Paolo Bonzini:
> On 25/06/2015 04:17, Zhu Guihua wrote:
>> Add a wrapper to specify reset order when registering reset handler,
>> instead of non-obvious initiazation code ordering.
>>
>> Signed-off-by: Zhu Guihua
>
> I'm sorry, this is not really acceptable. The i
On 25/06/2015 04:17, Zhu Guihua wrote:
> Add a wrapper to specify reset order when registering reset handler,
> instead of non-obvious initiazation code ordering.
>
> Signed-off-by: Zhu Guihua
I'm sorry, this is not really acceptable. The initialization code
ordering is good because it should
Am 25.06.2015 um 04:17 schrieb Zhu Guihua:
> Add a wrapper to specify reset order when registering reset handler,
> instead of non-obvious initiazation code ordering.
"initialization", and this sentence is not really telling to me.
What issue is this solving or, more likely, working around?
In t
Add a wrapper to specify reset order when registering reset handler,
instead of non-obvious initiazation code ordering.
Signed-off-by: Zhu Guihua
---
include/hw/hw.h | 4
vl.c| 18 +-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/include/hw/hw.h
13 matches
Mail list logo
