All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
To: BALATON Zoltan <balaton@eik.bme.hu>,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	f4bug@amsat.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v7 1/8] vt82c686: Implement control of serial port io ranges via config regs
Date: Tue, 23 Mar 2021 21:58:44 +0000	[thread overview]
Message-ID: <ef7a0bc6-3150-2f16-492f-5138fcee0b52@ilande.co.uk> (raw)
In-Reply-To: <a112d264-7540-9e4b-bc10-fe8e4518d828@eik.bme.hu>

On 23/03/2021 12:54, BALATON Zoltan wrote:

> On Wed, 10 Mar 2021, BALATON Zoltan wrote:
>> In VIA super south bridge the io ranges of superio components
>> (parallel and serial ports and FDC) can be controlled by superio
>> config registers to set their base address and enable/disable them.
>> This is not easy to implement in QEMU because ISA emulation is only
>> designed to set io base address once on creating the device and io
>> ranges are registered at creation and cannot easily be disabled or
>> moved later.
>>
>> In this patch we hack around that but only for serial ports because
>> those have a single io range at port base that's relatively easy to
>> handle and it's what guests actually use and set address different
>> than the default.
>>
>> We do not attempt to handle controlling the parallel and FDC regions
>> because those have multiple io ranges so handling them would be messy
>> and guests either don't change their deafult or don't care. We could
>> even get away with disabling and not emulating them, but since they
>> are already there, this patch leaves them mapped at their default
>> address just in case this could be useful for a guest in the future.
>>
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> 
> Could this patch be reviewed now please? I've dropped it from later versions to avoid 
> this holding back the series but now that it won't be in 6.0 I'd like to go back to 
> this. This is implementing the behaviour of the real hardware better than the 
> unsettable default value we have as a replacement. That approach also works for the 
> guests I've tried (MorphOS and Linux) but if we can do better than why not do it?

Do bear in mind that several people have already looked at this patch and haven't 
felt comfortable enough to review it, and I've also said in a previous email that 
this isn't the right approach. Given that the ISA bus partly uses the ioport address 
to reference the device, manually moving the memory regions around for devices on the 
bus without the ISA bus seeing those changes is going to cause issues.

IIRC the ability to dynamically change the standard ISA addresses was present in 
several motherboards from that era, and given that this functionality hasn't been 
implemented in QEMU this already tells us that no firmware is currently is using it.

I don't understand why using the hard-coded addresses in the v10 is a problem here? 
The addresses you added in the comments representing the programmed values are the 
standard ISA device addresses, so if those are what the firmware is programming then 
there will be no change. You also reported that it works fine with both your MorphOS 
and Linux test images, indicating that neither of these guest OSs require the feature.

If you find a guest OS that needs the functionality then certainly we can talk about 
trying to come up with a solution, but for me the extra complexity of this approach 
and the fact that you're overriding the management of the device by the ISA bus is 
why I haven't given it a R-B tag (I should add that my R-B for v10 using the 
hard-coded ISA addresses still stands).


ATB,

Mark.


  reply	other threads:[~2021-03-23 22:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10  2:58 [PATCH v7 0/8] Pegasos2 emulation BALATON Zoltan
2021-03-10  2:58 ` [PATCH v7 3/8] vt82c686: Add VT8231_SUPERIO based on VIA_SUPERIO BALATON Zoltan
2021-03-10  2:58 ` [PATCH v7 2/8] vt82c686: QOM-ify superio related functionality BALATON Zoltan
2021-03-11 23:50   ` Philippe Mathieu-Daudé
2021-03-12  0:32     ` BALATON Zoltan
2021-03-10  2:58 ` [PATCH v7 1/8] vt82c686: Implement control of serial port io ranges via config regs BALATON Zoltan
2021-03-11 23:47   ` Philippe Mathieu-Daudé
2021-03-12  1:20     ` David Gibson
2021-03-23 12:54   ` BALATON Zoltan
2021-03-23 21:58     ` Mark Cave-Ayland [this message]
2021-03-23 23:13       ` BALATON Zoltan
2021-03-10  2:58 ` [PATCH v7 8/8] hw/ppc: Add emulation of Genesi/bPlan Pegasos II BALATON Zoltan
2021-03-10  2:58 ` [PATCH v7 7/8] hw/pci-host: Add emulation of Marvell MV64361 PPC system controller BALATON Zoltan
2021-03-10  2:58 ` [PATCH v7 5/8] vt82c686: Add emulation of VT8231 south bridge BALATON Zoltan
2021-03-10  2:58 ` [PATCH v7 4/8] vt82c686: Introduce abstract TYPE_VIA_ISA and base vt82c686b_isa on it BALATON Zoltan
2021-03-10  2:58 ` [PATCH v7 6/8] hw/isa/Kconfig: Add missing dependency VIA VT82C686 -> APM BALATON Zoltan
2021-03-13 13:27 ` [PATCH v7 0/8] Pegasos2 emulation BALATON Zoltan
2021-03-15 12:33   ` BALATON Zoltan
2021-03-16  9:01     ` Laurent Vivier
2021-03-16 11:49       ` Philippe Mathieu-Daudé
2021-03-16 12:11         ` Laurent Vivier
2021-03-16 12:24           ` BALATON Zoltan
2021-03-16 12:55             ` Laurent Vivier
2021-03-16 13:06               ` BALATON Zoltan
2021-03-16 16:21                 ` Mark Cave-Ayland
2021-03-16 17:25                   ` BALATON Zoltan
2021-03-16 20:00                     ` Mark Cave-Ayland
2021-03-16 21:49                       ` BALATON Zoltan
2021-03-16 22:12                         ` BALATON Zoltan
2021-03-16 14:17         ` BALATON Zoltan
2021-03-16 14:48         ` BALATON Zoltan
2021-03-16 12:21       ` BALATON Zoltan

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=ef7a0bc6-3150-2f16-492f-5138fcee0b52@ilande.co.uk \
    --to=mark.cave-ayland@ilande.co.uk \
    --cc=balaton@eik.bme.hu \
    --cc=david@gibson.dropbear.id.au \
    --cc=f4bug@amsat.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.