From: Kevin Wolf <kwolf@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
jsnow@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org,
philmd@linaro.org, shentey@gmail.com,
Rene Engel <ReneEngel80@emailn.de>
Subject: Re: [PATCH v3 0/4] ide: implement simple legacy/native mode switching for PCI IDE controllers
Date: Mon, 20 Nov 2023 15:58:15 +0100 [thread overview]
Message-ID: <ZVt0B1pSsWWK7ReX@redhat.com> (raw)
In-Reply-To: <b9ea9c20-f9a5-9b79-6e70-624665fb5148@eik.bme.hu>
Am 20.11.2023 um 14:47 hat BALATON Zoltan geschrieben:
> On Mon, 20 Nov 2023, Kevin Wolf wrote:
> > Am 20.11.2023 um 14:09 hat BALATON Zoltan geschrieben:
> > > On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
> > > > The only difference I can think of regarding the BAR zeroing is that the
> > > > BMDMA BAR is zeroed here. Does the following diff fix things?
> > >
> > > This helps, with this the latest driver does not crash but still reads BAR4
> > > as 0 instead of 0xcc00 so UDMA won't work but at least it boots.
> >
> > And disabling only the first four BARs is actually what the spec says,
> > too. So I'll make this change to the queued patches.
> >
> > If I understand correctly, UDMA didn't work before this series either,
> > so it's a separate goal and doing it in its own patch is best anyway.
>
> UDMA works with my original series, did not work with earlier versions of
> this alternative from Mark but could be fixed up on top unless Mark can send
> a v4 now.
>
> > As we don't seem to have a good place to set a default, maybe just
> > overriding it in via_ide_cfg_read(), too, and making it return 0xcc01 in
> > compatibility mode is enough?
>
> I could give that a try and see if that helps but all this
> via_ide_cfg_read() seems like an unnecessary complication to me. Why can't
> we just set the BARs (o for BAR1-3 and default for BAR4) then we don't need
> to override config read?
I would be fine with setting 0xcc00 as the default value for BAR 4, but
as you said yourself, we can't do that in reset because it will be
overwritten by the PCI core code. Where else could we meaningfully do
that? As far as I understand, we don't have any hint that the
native/compatibility mode switch resets it on real hardware, so I'm
hesitant to do it there (and if the guest OS doesn't even switch, it
would never get set).
As for BAR 0-3, didn't we conclude that the via device still accepts I/O
to the configured addresses even though they read as zeros? Having
inconsistent config space and PCIIORegion seems like a bad idea, the
next call to pci_update_mappings() would break it.
Kevin
next prev parent reply other threads:[~2023-11-20 14:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-16 10:33 [PATCH v3 0/4] ide: implement simple legacy/native mode switching for PCI IDE controllers Mark Cave-Ayland
2023-11-16 10:33 ` [PATCH v3 1/4] ide/ioport: move ide_portio_list[] and ide_portio_list2[] definitions to IDE core Mark Cave-Ayland
2023-11-16 13:13 ` Philippe Mathieu-Daudé
2023-11-16 10:33 ` [PATCH v3 2/4] ide/pci: introduce pci_ide_update_mode() function Mark Cave-Ayland
2023-11-16 10:33 ` [PATCH v3 3/4] ide/via: don't attempt to set default BAR addresses Mark Cave-Ayland
2023-11-16 13:14 ` Philippe Mathieu-Daudé
2023-11-16 10:33 ` [PATCH v3 4/4] hw/ide/via: implement legacy/native mode switching Mark Cave-Ayland
2023-11-16 12:39 ` BALATON Zoltan
2023-11-16 13:48 ` [PATCH v3 0/4] ide: implement simple legacy/native mode switching for PCI IDE controllers Kevin Wolf
2023-11-16 21:59 ` BALATON Zoltan
2023-11-17 14:23 ` BALATON Zoltan
2023-11-20 10:17 ` Kevin Wolf
2023-11-20 11:10 ` BALATON Zoltan
2023-11-19 21:43 ` BALATON Zoltan
2023-11-19 22:11 ` BALATON Zoltan
2023-11-20 12:18 ` Mark Cave-Ayland
2023-11-20 13:09 ` BALATON Zoltan
2023-11-20 13:42 ` Kevin Wolf
2023-11-20 13:47 ` BALATON Zoltan
2023-11-20 14:00 ` BALATON Zoltan
2023-11-20 14:58 ` Kevin Wolf [this message]
2023-11-20 15:11 ` BALATON Zoltan
2023-11-21 9:48 ` Kevin Wolf
2023-11-20 14:28 ` Mark Cave-Ayland
2023-11-20 15:02 ` BALATON Zoltan
2023-11-21 9:12 ` Kevin Wolf
2023-11-21 10:16 ` Mark Cave-Ayland
2023-11-21 11:04 ` Peter Maydell
2023-11-20 12:26 ` Mark Cave-Ayland
2023-11-20 13:19 ` BALATON Zoltan
2023-11-20 13:30 ` BALATON Zoltan
2023-11-20 14:15 ` Mark Cave-Ayland
2023-11-20 14:58 ` 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=ZVt0B1pSsWWK7ReX@redhat.com \
--to=kwolf@redhat.com \
--cc=ReneEngel80@emailn.de \
--cc=balaton@eik.bme.hu \
--cc=jsnow@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shentey@gmail.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 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.