[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c |
Date: |
Wed, 01 Aug 2012 23:25:04 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 |
Am 01.08.2012 22:47, schrieb Anthony Liguori:
> Andreas Färber <address@hidden> writes:
>
>> Am 01.08.2012 22:02, schrieb Anthony Liguori:
>>> Devices do one of two things today:
>>>
>>> 1) register a reset callback
>>>
>>> 2) implement a reset method that is invoked through it's parent bus
>>>
>>> Since I don't expect CPUs to exist on a bus, it's not immediately clear
>>> to me that (1) isn't going to be what we do for quite some time.
>>
>> Err, I thought devices implement a function assigned to a
>> DeviceClass::reset, no? That would be (2) on your list and we've been
>> working on ripping out (1) for devices, on sPAPR for instance.
>> (2) is what we already have with CPUClass::reset.
>
> Something has to call DeviceClass::reset. That's done through a
> BusState. Whenever a bus is created, a qemu_register_reset() call is
> made to invoke the reset method on any device that's part of the bus.
>
> So just implementing DeviceClass::reset doesn't automatically mean the
> reset function will be called. In the short term, I think we'll need to
> still register a reset handler.
>
>> The only remaining issue is that the CPUClass::reset callback is not
>> automatically called on machine/bus reset yet.
>>
>> And what I was saying is that moving the code is NOT an improvement. It
>> is NO functional change and it is NOT a prerequisite for any change on
>> the list today. So it is not needed for the to be released 1.2.
>>
>> A very low hanging fruit for 1.2 would be to register a SINGLE central
>> reset callback that iterates through the globally available CPU list and
>> calls ->reset on each! Then we can drop the reset callbacks in most
>> machines rather than moving old code around.
>
> Relying on the CPU list for this isn't very QOM-like. A better approach
> would be to make all CPUs appear in a container and then have the reset
> propagate through container.
That doesn't work since our CPU modelling was going to be machine/SoC
specific. For x86, agreement seemed to be /machine/cpu[n]. For ARM,
Peter requested path/to/SoC/cortex/cpu[n].
I have just posted (and tested on x86_64) a really trivial patch that
avoids walking the CPU list, reuses existing infrastructure and lets us
drop the reset registration from target-i386, too. More reset callback
registrations can then be dropped as follow-ups from other machines.
Whether we walk a list or not, my point is to reduce redundancy. If it's
in one central location we can easily exchange the implementation. And I
do believe that calling my QOM method is very QOM-like rather than
besmearing my nice new CPUClass::reset concept by unnecessarily
introducing ugly old-style callbacks to my shiny QOM realize code. :)
Regards,
Andreas
>
> Reset is a complicated beast. While we model a single reset line today,
> this isn't technically correct. I believe the distinction between reset
> types start to matter with PCI-e actually.
>
> I do think any reduction in what's happening in machine is a net win.
> Even if we refactor this later, having the machine code do less and
> devices do more is an improvement.
>
> Regards,
>
> Anthony Liguori
>
>>
>> Regards,
>> Andreas
>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>>
>>>> Regards,
>>>> Andreas
>>>>
>>>> --
>>>> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>>> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>>>
>>
>>
>> --
>> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c,
Andreas Färber <=
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Peter Maydell, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Igor Mammedov, 2012/08/02
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01