_IO_IS_ISA question

[Benjamin Herrenschmidt]

> Hmmm. include/asm-ppc/io.h   ... twi ... isync ...
>
> I hope that we can do something that doesn't require either twi or isync,
> or sync for that matter, as the cure seems worse than the disease.
> I was assuming (and still kinda hoping) that a load/store to a bad
> ISA address would generate an exception that is synchronous with
> the load/store.

I added the twi,isync to all normal IOs recently for ppc64. This
is necessary. The problem is that you simply cannot expect driver
writers to understand how to deal with IO reads not beeing
synchronous. Also, an IO read is so slow in the first place that
I don't think the impact of doing a twi/isync will add any critical
performance loss, but then I may be wrong.

> Jake mentioned that exceptions are generated, but implied that the
> kernel tried to page-fault these in;  my biggest concern was to figure
> out how to elegantly pass these to the ex_table lookup table instead.

It depends how things are implented. If it's a machine check, then
those are essentially asynchronous, though ppc32 manages +/- to catch
them on the right instruction. If you don't map the IOs in the MMU,
then you get faults. There are 2 solutions at this point. Either
keep the fact they aren't mapped in the hash table while keeping the
linux page table mapping (ioremap), in which case you need some way to
catch errors in __hash_page without a panic, or change the PCI host
initialization to do mappings differently so that those holes aren't
mapped in the PTE (but the virtual space is still reserved), thus
causing normal kernel page faults. The later would work in non-HV
configs as well and already knows how to recover on ex_table.

> By 'cure worse than disease' I mean:  performance-wise, Jake's
> if-test ((port<10000) && maskbits) (and the half dozen insns that this
> genarates) sounds to be faster than sync, or so I would think ...
>
> --linas
>
> p.s. isync? I can't imagine why isync would have anything to do with io ...

isync ensures the twi got executed, which ensure the data loaded was
considered as "used" by the CPU, thus making the load effective. At
least this is my understanding ;)

Ben.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/