qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: BALATON Zoltan via <qemu-devel@nongnu.org>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>,
	qemu-block@nongnu.org, Huacai Chen <chenhuacai@kernel.org>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	qemu-devel@nongnu.org,
	Wainer dos Santos Moschetta <wainersm@redhat.com>,
	Aurelien Jarno <aurelien@aurel32.net>,
	Cleber Rosa <crosa@redhat.com>, John Snow <jsnow@redhat.com>,
	Artyom Tarasenko <atar4qemu@gmail.com>
Subject: Re: [RFC PATCH 0/5] hw/mips: Fix Fuloong2E to boot Linux guest again
Date: Sat, 2 Jan 2021 00:56:44 +0100 (CET)	[thread overview]
Message-ID: <eb1af512-943e-f65c-d867-3ead1eccb5d5@eik.bme.hu> (raw)
In-Reply-To: <20210101231215.1870611-1-f4bug@amsat.org>

[-- Attachment #1: Type: text/plain, Size: 4919 bytes --]

On Sat, 2 Jan 2021, Philippe Mathieu-Daudé wrote:
> We closed 2020 with few discussions about the Fuloong 2E board
> (see [1] and [2]).
>
> This series collect the minimum set of patch to have the machine
> booting Linux guest again, including integration tests.
>
> This is sent as RFC because Mark raised some issues in (see [3]
> and previous in this thread) and I don't understand PCI enough
> to intervene.

Thanks for collecting these. Let me summarise the discussion because the 
meaning may have been lost in the seamingly heated debate but I think 
Mark's main concern was that he does not like having a feature flag and 
property setting the emulation to partially emulate the device: either 
only emulating legacy mode or native mode that this patch does but he 
would prefer to faithfully emulate the device preferably allowing 
switching between modes. But that's not easily possible without rewritig 
either the ISA emulation or PCI emulation in QEMU because current code 
does not allow these to be switched once created. That's way more work and 
risk of breaking other things using these fundamental parts that I would 
want to take on. My goal was only to allow using this (otherwise quite 
unused and deglected) device model in pegasos2 emulation which needs 
native mode. But turns out fuloong2e Linux wants legacy mode so we need a 
way to resolve this conflict and the solution was this flag and keeping 
partial emulation depending on machine.

But Mark still considered that a horrible hack but after looking more 
closely he also found the difficulty of implementing a more faithful 
emulation so he would accept the flag at the end but still wanted 
registers to be set more consistently matching what the data sheet and 
whatever ideals would dictate. However I've spent a lot of time before 
finding these values that work with all clients and found some of these 
clients have assumptions instead of working in an ideal world following 
what data sheets say and I don't want to make any changes to this now 
before we also have pegasos2 upstreamed so any change can be more 
throughly tested and I don't have to retest everything for every small 
change just to find something broke,

This was the main reason for disagreement and I think Mark's standards for 
this device was way higher than necessary in this situation and I may have 
got upset to have this pushed back again when we've already went through 
this last March where we also had a long discussion after which Mark 
managed to get rid of the flag but that now came back in a different form. 
(Previously it was switching between fully native and non-100% native 
mode, now it selects legacy or non-100% native mode where legacy is needed 
for fuloong2e linux and non-100% native mode is needed for pegasos2 
guests.) This may not be how the real device work (Mark also has concerns 
about what exactly is non-100% native mode) and it may be a horrible hack 
but it's probably the best that can be done with current QEMU facilities 
and in the time I had and since this is only used on fuloong2e and 
pegasos2 for a few obscure guests I think it does not need any more 
complex solution at the moment.

It seems this disagreement on what's good enough for a device model to get 
in QEMU is the source of disagreement between us with Mark but we'll sort 
that out off list once I finish preparing my pegasos2 patches that will 
finally show where these changes go and oters can also test any proposed 
changes.

Regards,
BALATON Zoltan

> Peter commented a similar PCI issue with the Sam460ex [4] so might
> be able to help us here.
>
> Anyhow, sharing this PoC on the list with the test, the avoid boring
> manual testing.
>
> Regards,
>
> Phil.
>
> [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg769105.html
> [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg769557.html
> [3] https://www.mail-archive.com/qemu-devel@nongnu.org/msg769593.html
> [4] https://www.mail-archive.com/qemu-devel@nongnu.org/msg769697.html
>
> BALATON Zoltan (1):
>  ide: Make room for flags in PCIIDEState and add one for legacy mode
>
> Guenter Roeck (1):
>  via-ide: Fix fuloong2e support
>
> Jiaxun Yang (1):
>  tests/acceptance: Test boot_linux_console for fuloong2e
>
> Philippe Mathieu-Daudé (2):
>  hw/pci-host/bonito: Remap PCI "lo" regions when PCIMAP reg is modified
>  tests/integration: Test Fuloong2E IDE drive, run userspace commands
>
> include/hw/ide/pci.h                   |  7 +++-
> hw/ide/cmd646.c                        |  6 ++--
> hw/ide/via.c                           | 19 ++++++++--
> hw/mips/fuloong2e.c                    |  4 ++-
> hw/pci-host/bonito.c                   | 49 +++++++++++++++++++-------
> hw/sparc64/sun4u.c                     |  2 +-
> tests/acceptance/boot_linux_console.py | 47 ++++++++++++++++++++++++
> 7 files changed, 113 insertions(+), 21 deletions(-)
>
> --
> 2.26.2
>
>
>

  parent reply	other threads:[~2021-01-01 23:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-01 23:12 [RFC PATCH 0/5] hw/mips: Fix Fuloong2E to boot Linux guest again Philippe Mathieu-Daudé
2021-01-01 23:12 ` [RFC PATCH 1/5] ide: Make room for flags in PCIIDEState and add one for legacy mode Philippe Mathieu-Daudé
2021-01-01 23:12 ` [RFC PATCH 2/5] via-ide: Fix fuloong2e support Philippe Mathieu-Daudé
2021-01-03 15:14   ` Mark Cave-Ayland
2021-01-03 18:31     ` BALATON Zoltan via
2021-01-01 23:12 ` [RFC PATCH 3/5] hw/pci-host/bonito: Remap PCI "lo" regions when PCIMAP reg is modified Philippe Mathieu-Daudé
2021-01-01 23:19   ` Peter Maydell
2021-01-02 10:44     ` Philippe Mathieu-Daudé
2021-01-02 10:56       ` Philippe Mathieu-Daudé
2021-01-02 11:22       ` BALATON Zoltan via
2021-01-02 13:10         ` Peter Maydell
2021-01-02 14:12           ` BALATON Zoltan via
2021-01-01 23:12 ` [RFC PATCH 4/5] tests/acceptance: Test boot_linux_console for fuloong2e Philippe Mathieu-Daudé
2021-01-01 23:12 ` [RFC PATCH 5/5] tests/integration: Test Fuloong2E IDE drive, run userspace commands Philippe Mathieu-Daudé
2021-01-06 12:49   ` Willian Rampazzo
2021-01-01 23:56 ` BALATON Zoltan via [this message]
2021-01-03 14:27   ` [RFC PATCH 0/5] hw/mips: Fix Fuloong2E to boot Linux guest again Mark Cave-Ayland
2021-01-03 16:04     ` BALATON Zoltan via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eb1af512-943e-f65c-d867-3ead1eccb5d5@eik.bme.hu \
    --to=qemu-devel@nongnu.org \
    --cc=aleksandar.rikalo@syrmia.com \
    --cc=atar4qemu@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=balaton@eik.bme.hu \
    --cc=chenhuacai@kernel.org \
    --cc=crosa@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=jsnow@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-block@nongnu.org \
    --cc=wainersm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).