mbox

[PULL] qemu-sparc update

Message ID 20150304062009.GB8014@kentang.lan
State New
Headers show

Pull-request

https://github.com/mcayland/qemu.git tags/qemu-sparc-signed

Message

Mark Cave-Ayland March 4, 2015, 6:20 a.m. UTC
Hi Peter,

Here are the updates from my qemu-sparc tree. Please pull.


ATB,

Mark.


The following changes since commit b8a173b25c887a606681fc35a46702c164d5b2d0:

  Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging (2015-03-02 14:25:48 +0000)

are available in the git repository at:


  https://github.com/mcayland/qemu.git tags/qemu-sparc-signed

for you to fetch changes up to ed646b4c8fba426b67d1ad2da40861b4dc6745f9:

  sun4u: switch m48t59 NVRAM to MMIO access (2015-03-03 22:53:31 +0000)

----------------------------------------------------------------
qemu-sparc update

----------------------------------------------------------------
Hervé Poussineau (4):
      m48t59: move ISA ports/memory regions registration to QOM constructor
      m48t59: register a QOM type for each nvram type we support
      m48t59: add a Nvram interface
      m48t59: let init functions return a Nvram object

Mark Cave-Ayland (5):
      m48t59: introduce new base-year qdev property
      m48t59: add m48t59 sysbus device
      doc: minor updates to SPARC32 and SPARC64 documentation
      MAINTAINERS: add myself as SPARC maintainer
      sun4u: switch m48t59 NVRAM to MMIO access

 MAINTAINERS               |    3 +
 hw/ppc/ppc.c              |  161 --------------------
 hw/ppc/ppc405_boards.c    |    2 +-
 hw/ppc/prep.c             |  163 ++++++++++++++++++--
 hw/sparc/sun4m.c          |   10 +-
 hw/sparc64/sun4u.c        |   20 ++-
 hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
 include/hw/timer/m48t59.h |   61 ++++----
 pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
 qemu-doc.texi             |    7 +-
 10 files changed, 463 insertions(+), 323 deletions(-)

Comments

Peter Maydell March 8, 2015, 9:47 a.m. UTC | #1
On 4 March 2015 at 15:20, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> Hi Peter,
>
> Here are the updates from my qemu-sparc tree. Please pull.

>  MAINTAINERS               |    3 +
>  hw/ppc/ppc.c              |  161 --------------------
>  hw/ppc/ppc405_boards.c    |    2 +-
>  hw/ppc/prep.c             |  163 ++++++++++++++++++--
>  hw/sparc/sun4m.c          |   10 +-
>  hw/sparc64/sun4u.c        |   20 ++-
>  hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
>  include/hw/timer/m48t59.h |   61 ++++----
>  pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
>  qemu-doc.texi             |    7 +-

Shouldn't there be an update to roms/openbios to go with the
pc-bios/openbios-sparc64 binary blob update?

-- PMM
Mark Cave-Ayland March 8, 2015, 10:04 a.m. UTC | #2
On 08/03/15 09:47, Peter Maydell wrote:

> On 4 March 2015 at 15:20, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> Hi Peter,
>>
>> Here are the updates from my qemu-sparc tree. Please pull.
> 
>>  MAINTAINERS               |    3 +
>>  hw/ppc/ppc.c              |  161 --------------------
>>  hw/ppc/ppc405_boards.c    |    2 +-
>>  hw/ppc/prep.c             |  163 ++++++++++++++++++--
>>  hw/sparc/sun4m.c          |   10 +-
>>  hw/sparc64/sun4u.c        |   20 ++-
>>  hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
>>  include/hw/timer/m48t59.h |   61 ++++----
>>  pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
>>  qemu-doc.texi             |    7 +-
> 
> Shouldn't there be an update to roms/openbios to go with the
> pc-bios/openbios-sparc64 binary blob update?

I haven't committed the sun4u MMIO patches to OpenBIOS yet because
without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and the
QEMU parts have taken many weeks to get right which is a long time to
leave things broken). Hence I've gone for just updating the binary which
is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve
bisection.

As soon as this is applied, I can apply my remaining OpenBIOS patches
and then send a separate qemu-openbios pull request which will bring
everything up to date.


ATB,

Mark.
Peter Maydell March 8, 2015, 10:31 a.m. UTC | #3
On 8 March 2015 at 19:04, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> On 08/03/15 09:47, Peter Maydell wrote:
>
>> On 4 March 2015 at 15:20, Mark Cave-Ayland
>> <mark.cave-ayland@ilande.co.uk> wrote:
>>> Hi Peter,
>>>
>>> Here are the updates from my qemu-sparc tree. Please pull.
>>
>>>  MAINTAINERS               |    3 +
>>>  hw/ppc/ppc.c              |  161 --------------------
>>>  hw/ppc/ppc405_boards.c    |    2 +-
>>>  hw/ppc/prep.c             |  163 ++++++++++++++++++--
>>>  hw/sparc/sun4m.c          |   10 +-
>>>  hw/sparc64/sun4u.c        |   20 ++-
>>>  hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
>>>  include/hw/timer/m48t59.h |   61 ++++----
>>>  pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
>>>  qemu-doc.texi             |    7 +-
>>
>> Shouldn't there be an update to roms/openbios to go with the
>> pc-bios/openbios-sparc64 binary blob update?
>
> I haven't committed the sun4u MMIO patches to OpenBIOS yet because
> without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and the
> QEMU parts have taken many weeks to get right which is a long time to
> leave things broken). Hence I've gone for just updating the binary which
> is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve
> bisection.
>
> As soon as this is applied, I can apply my remaining OpenBIOS patches
> and then send a separate qemu-openbios pull request which will bring
> everything up to date.

Hmm. I'm not a huge fan of having the binary in git and the submodule
reference be out of step...

Alex, I guess PPC is the other openbios user -- does this make sense
to you?

-- PMM
Mark Cave-Ayland March 8, 2015, 10:57 a.m. UTC | #4
On 08/03/15 10:31, Peter Maydell wrote:

> On 8 March 2015 at 19:04, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> On 08/03/15 09:47, Peter Maydell wrote:
>>
>>> On 4 March 2015 at 15:20, Mark Cave-Ayland
>>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>> Hi Peter,
>>>>
>>>> Here are the updates from my qemu-sparc tree. Please pull.
>>>
>>>>  MAINTAINERS               |    3 +
>>>>  hw/ppc/ppc.c              |  161 --------------------
>>>>  hw/ppc/ppc405_boards.c    |    2 +-
>>>>  hw/ppc/prep.c             |  163 ++++++++++++++++++--
>>>>  hw/sparc/sun4m.c          |   10 +-
>>>>  hw/sparc64/sun4u.c        |   20 ++-
>>>>  hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
>>>>  include/hw/timer/m48t59.h |   61 ++++----
>>>>  pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
>>>>  qemu-doc.texi             |    7 +-
>>>
>>> Shouldn't there be an update to roms/openbios to go with the
>>> pc-bios/openbios-sparc64 binary blob update?
>>
>> I haven't committed the sun4u MMIO patches to OpenBIOS yet because
>> without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and the
>> QEMU parts have taken many weeks to get right which is a long time to
>> leave things broken). Hence I've gone for just updating the binary which
>> is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve
>> bisection.
>>
>> As soon as this is applied, I can apply my remaining OpenBIOS patches
>> and then send a separate qemu-openbios pull request which will bring
>> everything up to date.
> 
> Hmm. I'm not a huge fan of having the binary in git and the submodule
> reference be out of step...

Alternatively if you have shell access to git.qemu.org then I can commit
just the MMIO accessor changes to SVN trunk now and then with a manual
update to the OpenBIOS git mirror I can re-send the signed pull request
with updated binaries? I've deliberately held off applying patches to
OpenBIOS SVN trunk in case this was the preferred method as I'm keen to
be able to bisect down to this particular change on SPARC64.


ATB,

Mark.
Alexander Graf March 8, 2015, 8:48 p.m. UTC | #5
On 08.03.15 06:57, Mark Cave-Ayland wrote:
> On 08/03/15 10:31, Peter Maydell wrote:
> 
>> On 8 March 2015 at 19:04, Mark Cave-Ayland
>> <mark.cave-ayland@ilande.co.uk> wrote:
>>> On 08/03/15 09:47, Peter Maydell wrote:
>>>
>>>> On 4 March 2015 at 15:20, Mark Cave-Ayland
>>>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>>> Hi Peter,
>>>>>
>>>>> Here are the updates from my qemu-sparc tree. Please pull.
>>>>
>>>>>  MAINTAINERS               |    3 +
>>>>>  hw/ppc/ppc.c              |  161 --------------------
>>>>>  hw/ppc/ppc405_boards.c    |    2 +-
>>>>>  hw/ppc/prep.c             |  163 ++++++++++++++++++--
>>>>>  hw/sparc/sun4m.c          |   10 +-
>>>>>  hw/sparc64/sun4u.c        |   20 ++-
>>>>>  hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
>>>>>  include/hw/timer/m48t59.h |   61 ++++----
>>>>>  pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
>>>>>  qemu-doc.texi             |    7 +-
>>>>
>>>> Shouldn't there be an update to roms/openbios to go with the
>>>> pc-bios/openbios-sparc64 binary blob update?
>>>
>>> I haven't committed the sun4u MMIO patches to OpenBIOS yet because
>>> without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and the
>>> QEMU parts have taken many weeks to get right which is a long time to
>>> leave things broken). Hence I've gone for just updating the binary which
>>> is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve
>>> bisection.
>>>
>>> As soon as this is applied, I can apply my remaining OpenBIOS patches
>>> and then send a separate qemu-openbios pull request which will bring
>>> everything up to date.
>>
>> Hmm. I'm not a huge fan of having the binary in git and the submodule
>> reference be out of step...
> 
> Alternatively if you have shell access to git.qemu.org then I can commit
> just the MMIO accessor changes to SVN trunk now and then with a manual
> update to the OpenBIOS git mirror I can re-send the signed pull request
> with updated binaries? I've deliberately held off applying patches to
> OpenBIOS SVN trunk in case this was the preferred method as I'm keen to
> be able to bisect down to this particular change on SPARC64.

Is there any way to make the change backwards compatible, so that we
don't need to sync versions?


Alex
Mark Cave-Ayland March 8, 2015, 9:03 p.m. UTC | #6
On 08/03/15 20:48, Alexander Graf wrote:

> On 08.03.15 06:57, Mark Cave-Ayland wrote:
>> On 08/03/15 10:31, Peter Maydell wrote:
>>
>>> On 8 March 2015 at 19:04, Mark Cave-Ayland
>>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>> On 08/03/15 09:47, Peter Maydell wrote:
>>>>
>>>>> On 4 March 2015 at 15:20, Mark Cave-Ayland
>>>>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>>>> Hi Peter,
>>>>>>
>>>>>> Here are the updates from my qemu-sparc tree. Please pull.
>>>>>
>>>>>>  MAINTAINERS               |    3 +
>>>>>>  hw/ppc/ppc.c              |  161 --------------------
>>>>>>  hw/ppc/ppc405_boards.c    |    2 +-
>>>>>>  hw/ppc/prep.c             |  163 ++++++++++++++++++--
>>>>>>  hw/sparc/sun4m.c          |   10 +-
>>>>>>  hw/sparc64/sun4u.c        |   20 ++-
>>>>>>  hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
>>>>>>  include/hw/timer/m48t59.h |   61 ++++----
>>>>>>  pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
>>>>>>  qemu-doc.texi             |    7 +-
>>>>>
>>>>> Shouldn't there be an update to roms/openbios to go with the
>>>>> pc-bios/openbios-sparc64 binary blob update?
>>>>
>>>> I haven't committed the sun4u MMIO patches to OpenBIOS yet because
>>>> without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and the
>>>> QEMU parts have taken many weeks to get right which is a long time to
>>>> leave things broken). Hence I've gone for just updating the binary which
>>>> is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve
>>>> bisection.
>>>>
>>>> As soon as this is applied, I can apply my remaining OpenBIOS patches
>>>> and then send a separate qemu-openbios pull request which will bring
>>>> everything up to date.
>>>
>>> Hmm. I'm not a huge fan of having the binary in git and the submodule
>>> reference be out of step...
>>
>> Alternatively if you have shell access to git.qemu.org then I can commit
>> just the MMIO accessor changes to SVN trunk now and then with a manual
>> update to the OpenBIOS git mirror I can re-send the signed pull request
>> with updated binaries? I've deliberately held off applying patches to
>> OpenBIOS SVN trunk in case this was the preferred method as I'm keen to
>> be able to bisect down to this particular change on SPARC64.
> 
> Is there any way to make the change backwards compatible, so that we
> don't need to sync versions?

Not without refactoring to enable more than one type of NVRAM accessor
in OpenBIOS, plus a fw_cfg variable to enable the switch between the two
for SPARC64.

Given that SPARC64 is still more experimental than stable plus newer
versions of OpenBIOS aren't guaranteed to work with older versions of
QEMU anyhow, I just can't see that this is worth all the extra effort
for the sake of a follow-up pull request within a day or so that will
bring everything up to date whilst still allowing a proper bisection.

Now if Peter is still keen to keep the git submodule reference intact
then I'm happy to commit just the MMIO accessor changes to OpenBIOS SVN
trunk as long as we can minimise the time between the QEMU changes and
the OpenBIOS changes.


ATB,

Mark.
Alexander Graf March 8, 2015, 9:05 p.m. UTC | #7
> Am 08.03.2015 um 17:03 schrieb Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
> 
>> On 08/03/15 20:48, Alexander Graf wrote:
>> 
>>> On 08.03.15 06:57, Mark Cave-Ayland wrote:
>>>> On 08/03/15 10:31, Peter Maydell wrote:
>>>> 
>>>> On 8 March 2015 at 19:04, Mark Cave-Ayland
>>>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>>> On 08/03/15 09:47, Peter Maydell wrote:
>>>>> 
>>>>>> On 4 March 2015 at 15:20, Mark Cave-Ayland
>>>>>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>>>>> Hi Peter,
>>>>>>> 
>>>>>>> Here are the updates from my qemu-sparc tree. Please pull.
>>>>>> 
>>>>>>> MAINTAINERS               |    3 +
>>>>>>> hw/ppc/ppc.c              |  161 --------------------
>>>>>>> hw/ppc/ppc405_boards.c    |    2 +-
>>>>>>> hw/ppc/prep.c             |  163 ++++++++++++++++++--
>>>>>>> hw/sparc/sun4m.c          |   10 +-
>>>>>>> hw/sparc64/sun4u.c        |   20 ++-
>>>>>>> hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
>>>>>>> include/hw/timer/m48t59.h |   61 ++++----
>>>>>>> pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
>>>>>>> qemu-doc.texi             |    7 +-
>>>>>> 
>>>>>> Shouldn't there be an update to roms/openbios to go with the
>>>>>> pc-bios/openbios-sparc64 binary blob update?
>>>>> 
>>>>> I haven't committed the sun4u MMIO patches to OpenBIOS yet because
>>>>> without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and the
>>>>> QEMU parts have taken many weeks to get right which is a long time to
>>>>> leave things broken). Hence I've gone for just updating the binary which
>>>>> is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve
>>>>> bisection.
>>>>> 
>>>>> As soon as this is applied, I can apply my remaining OpenBIOS patches
>>>>> and then send a separate qemu-openbios pull request which will bring
>>>>> everything up to date.
>>>> 
>>>> Hmm. I'm not a huge fan of having the binary in git and the submodule
>>>> reference be out of step...
>>> 
>>> Alternatively if you have shell access to git.qemu.org then I can commit
>>> just the MMIO accessor changes to SVN trunk now and then with a manual
>>> update to the OpenBIOS git mirror I can re-send the signed pull request
>>> with updated binaries? I've deliberately held off applying patches to
>>> OpenBIOS SVN trunk in case this was the preferred method as I'm keen to
>>> be able to bisect down to this particular change on SPARC64.
>> 
>> Is there any way to make the change backwards compatible, so that we
>> don't need to sync versions?
> 
> Not without refactoring to enable more than one type of NVRAM accessor
> in OpenBIOS, plus a fw_cfg variable to enable the switch between the two
> for SPARC64.
> 
> Given that SPARC64 is still more experimental than stable plus newer
> versions of OpenBIOS aren't guaranteed to work with older versions of
> QEMU anyhow, I just can't see that this is worth all the extra effort
> for the sake of a follow-up pull request within a day or so that will
> bring everything up to date whilst still allowing a proper bisection.
> 
> Now if Peter is still keen to keep the git submodule reference intact
> then I'm happy to commit just the MMIO accessor changes to OpenBIOS SVN
> trunk as long as we can minimise the time between the QEMU changes and
> the OpenBIOS changes.

Yes, I think that's a reasonable way forward. Maybe add a fw_cfg and assert() on it nevertheless, so people don't fall into pits ;).


Alex
Mark Cave-Ayland March 9, 2015, 9:32 a.m. UTC | #8
On 08/03/15 21:05, Alexander Graf wrote:

>> Am 08.03.2015 um 17:03 schrieb Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
>>
>>> On 08/03/15 20:48, Alexander Graf wrote:
>>>
>>>> On 08.03.15 06:57, Mark Cave-Ayland wrote:
>>>>> On 08/03/15 10:31, Peter Maydell wrote:
>>>>>
>>>>> On 8 March 2015 at 19:04, Mark Cave-Ayland
>>>>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>>>> On 08/03/15 09:47, Peter Maydell wrote:
>>>>>>
>>>>>>> On 4 March 2015 at 15:20, Mark Cave-Ayland
>>>>>>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>> Here are the updates from my qemu-sparc tree. Please pull.
>>>>>>>
>>>>>>>> MAINTAINERS               |    3 +
>>>>>>>> hw/ppc/ppc.c              |  161 --------------------
>>>>>>>> hw/ppc/ppc405_boards.c    |    2 +-
>>>>>>>> hw/ppc/prep.c             |  163 ++++++++++++++++++--
>>>>>>>> hw/sparc/sun4m.c          |   10 +-
>>>>>>>> hw/sparc64/sun4u.c        |   20 ++-
>>>>>>>> hw/timer/m48t59.c         |  359 ++++++++++++++++++++++++++++++++-------------
>>>>>>>> include/hw/timer/m48t59.h |   61 ++++----
>>>>>>>> pc-bios/openbios-sparc64  |  Bin 1616768 -> 1616768 bytes
>>>>>>>> qemu-doc.texi             |    7 +-
>>>>>>>
>>>>>>> Shouldn't there be an update to roms/openbios to go with the
>>>>>>> pc-bios/openbios-sparc64 binary blob update?
>>>>>>
>>>>>> I haven't committed the sun4u MMIO patches to OpenBIOS yet because
>>>>>> without the corresponding QEMU parts OpenBIOS SVN trunk breaks (and the
>>>>>> QEMU parts have taken many weeks to get right which is a long time to
>>>>>> leave things broken). Hence I've gone for just updating the binary which
>>>>>> is SVN trunk plus the NVRAM MMIO accessor changes in order to preserve
>>>>>> bisection.
>>>>>>
>>>>>> As soon as this is applied, I can apply my remaining OpenBIOS patches
>>>>>> and then send a separate qemu-openbios pull request which will bring
>>>>>> everything up to date.
>>>>>
>>>>> Hmm. I'm not a huge fan of having the binary in git and the submodule
>>>>> reference be out of step...
>>>>
>>>> Alternatively if you have shell access to git.qemu.org then I can commit
>>>> just the MMIO accessor changes to SVN trunk now and then with a manual
>>>> update to the OpenBIOS git mirror I can re-send the signed pull request
>>>> with updated binaries? I've deliberately held off applying patches to
>>>> OpenBIOS SVN trunk in case this was the preferred method as I'm keen to
>>>> be able to bisect down to this particular change on SPARC64.
>>>
>>> Is there any way to make the change backwards compatible, so that we
>>> don't need to sync versions?
>>
>> Not without refactoring to enable more than one type of NVRAM accessor
>> in OpenBIOS, plus a fw_cfg variable to enable the switch between the two
>> for SPARC64.
>>
>> Given that SPARC64 is still more experimental than stable plus newer
>> versions of OpenBIOS aren't guaranteed to work with older versions of
>> QEMU anyhow, I just can't see that this is worth all the extra effort
>> for the sake of a follow-up pull request within a day or so that will
>> bring everything up to date whilst still allowing a proper bisection.
>>
>> Now if Peter is still keen to keep the git submodule reference intact
>> then I'm happy to commit just the MMIO accessor changes to OpenBIOS SVN
>> trunk as long as we can minimise the time between the QEMU changes and
>> the OpenBIOS changes.
> 
> Yes, I think that's a reasonable way forward. Maybe add a fw_cfg and assert() on it nevertheless, so people don't fall into pits ;).

If you're trying to run an old SPARC32/64 OpenBIOS on a newer QEMU then
there are already several pits you could have fallen into ;)  And given
that no-one has reported any issues with this to date then I don't think
it will be a problem.

As it looks like this will happen shortly, I'll go commit the MMIO
changes for SPARC64 to OpenBIOS SVN trunk now. Then as soon as the git
mirror syncs I'll send an updated PULLv2 for Peter.


ATB,

Mark.