Re: [UPDATED PATCH] IP28 support

[Richard Sandiford <rsandifo@nildram.co.uk>]

peter fuerst <post@pfrst.de> writes:
>> compile-time base+offset addresses.  And as I said, the compiler is
>> free to make up accesses that aren't in fact valid for cases where
>> the access isn't made.  E.g. if you had a loop with a stride of 128,
>> the compiler could unroll the loop as many times as it likes.  Some
>> of the unrolled iterations might access areas outside the stack frame.
>
> You mean, the compiler would generate $sp+const_int accesses here, whose
> validity is not known at compile-time - similar to foo() above ?

Right.

>> I think you're missing my point.  If you access an I/O-mapped device
>> through KSEG2 or an uncached XKPHYS address, is it not also physically
>> possible (though clearly unwise) to access it through KSEG0 or a cached
>> XKPHYS address too?  So can you guarantee that every const_int cached
>> address in a multi-platform kernel is not I/O-mapped on any of the r10k
>> platforms?  Or can you guarantee that the compiler will not manufacture
>> such an address from an otherwise harmless address?
> Hmm, it's not quite clear, how it could be manufactured.

Similar to the above really, for combinations of suitably bizarre input
code and compiler behaviour.  Again, the problem isn't that such a thing
is _likely_ to happen, just that it wouldn't be wrong for it to happen in
non-r10k situations (and thus not likely to be treated as a "wrong-code"
bug by gcc developers).

>>                                                     Again, the key thing
>> is to think about what the compiler can validly do on non-r10k platforms,
>> however silly it might seem, and then make sure the workarounds cope
>> with it.
>
> Do you think of accesses that essentially look like this ?
>
>   if (machine_x)
>      *uncached(const_addr) = val;
>   else
>      *cached(const_addr) = val;

Well, more generally, I was thinking of something like:


    if (machine_x)
      *cached(const_addr1) = ...;
    else
      ...blah...

where const_addr1 might be harmful if !machine_x.

> Fortunately (at least? even?) on IP28 cached access (hence a block read
> request) to an I/O-device address is a non-issue. In this respect the
> hardware design seems to follow the recommendations from the R10000 manual
> (NACK from external agent?):
> - if such an access graduates (i.e. a "real" access), a bus-error will occur.
> - if not (i.e. mis-speculated), nothing happens.

Ah, OK.  That's what I was missing, thanks.  (I suspect you and Ralf
have explained that to me before, but it hadn't sunk in.  Sorry!)

> However, i don't yet know, how O2 behaves, or, if there exists any other
> R10k-machine, which would need the software-workaround.

OK.

In that case, for the IP28 at least, I think the only issue with excluding
cachable const_int addresses is that the compiler might somehow conspire to
create an address that turns out to be, for some runs at least, an address
in a DMA buffer.

> Well, the option spec could be as listed above. With "store" as default
> for an empty option-string ("none" as default if the option isn't given
> at all).

Sounds good.

Thanks, it seems we have a plan ;)

Richard