Re: s3 doesn't work on non i386/amd64

Hello,

On Tue, 15 Nov 2022 17:21:34 -0000 (UTC)
T <[email protected]> wrote:

> > Xorg stopped working for me after upgrading from NetBSD 8.x to 9.x and
> > hasn't worked since, it always segfaults. There is the Xorg log output
> > posted on the port-prep mailing list, although it does not really
> > provide any specific clues to the root cause. I've recently used GDB on
> > Xorg with debug sets and believe the problem was introduced when some
> > changes were made to the s3 driver and a few related files. The
> > backtrace output is also on the port-prep mailing list.
> > 
> > The flow is:
> > vgaHWSetStdFuncs(hwp) ->
> > ci_legacy_open_io(hwp->dev, 0, 64 * 1024) ->
> > !pci_sys->methods->open_legacy_io(ret, dev, base, size) -> resolves to:
> > pci_device_netbsd_open_legacy_io(...)
> > 
> > ...  

Hmm, the driver unconditionally calls vgaHWSetStdFuncs(). On non-x86 it
should really use vgaHWSetMmioFuncs(hwp, ioBase, 0), assuming the
earlier call to xf86EnableIO() succeeded. You should see something like
this in your Xorg.0.log:

[   152.103] (--) using VT number 5
[   152.111] (WW) xf86EnableIO 9
[   152.111] (II) xf86EnableIO: 0xfca00000
[   152.111] (EE) xf86BusConfig: hwaccess 1
[   152.111] (WW) xf86EnableIO 9
[   152.112] (EE) xf86BusConfig: 1 drivers
[   152.112] (EE) trying nv

> =========================================================================
> > 
> > This always returns a NULL handle because the system I'm using is
> > not i386 or amd64. This causes this to segfault:
> > vgaHWGetIOBase(hwp) ->
> > hwp->readMiscOut(hwp) -> resolves to:
> > stdReadMiscOut(vgaHWPtr hwp) -> which calls:
> > pci_io_read8(hwp->io, VGA_MISC_OUT_R) ->
> > segfault, as hwp->io is 0x0
> > 
> > ...  
> =========================================================================
> > 
> > It would seem that pci_device_netbsd_open_legacy_io(...) would need
> > to be modified to allow for non x86 systems to use the s3 driver.  

Hmm, we have several non-x86 ports that access PCI IO space in Xorg,
although none that I have access to use the S3 driver. Basically, we
map the IO space through the console fd, that way we get the IO space
the console lives in. I never got around to implement proper per-domain
PIO access but in about 99.9% of all cases that's what you need. See
hw/xfree86/os-support/bsd.ppc_video.c. That file name is a bit of a
misnomer, it's used on a few decidedly non-ppc ports.  

> I received some feedback in IRC:
> 
> "That function is for getting a port IO handle. Port IO itself is x86 
> centric. On archs other than x86 there generally is not a concept of port 
> IO at all, the function returns NULL if it can't get access to port IO, 
> and that can only happen via an IOPL call so when on a non-x86 arch it 
> should fail. Well, there's probably other ways to access the PCI I/O 
> address space. I think it's usually mappable, and netbsd probably uses it 
> for something. I'm not sure what options userspace would have for 
> accessing it in that case though."
> 
> "vgaHW.c is missing error branches in the event pci_legacy_open_io fails"

It should probably not fail on ports that have PCI_MAGIC_IO_RANGE since
there we can map PCI IO automatically.
It's defined on prep, so that part should Just Work(tm).

have fun
Michael