Re: [Qemu-devel] [PULL v2 0/7] s390x patches for 2.3

[Cornelia Huck]

On Sat, 20 Dec 2014 22:03:34 +0000
Peter Maydell <address@hidden> wrote:

> On 18 December 2014 at 16:34, Cornelia Huck <address@hidden> wrote:
> > Next try for s390x updates. The previous build failures should be
> > fixed now.
> 
> Still not building on w32, I'm afraid. I think most of this is run-on
> error from using __uint16_t &c rather than uint16_t &c.

Sigh. Every time I try to set up a mingw build environment, I get lost
in some library dependencies and give up.

But yes, the __uint* stuff looks like some copy&paste error from the
respective Linux headers. I'll leave it to Frank to fix that up.

> 
> You also have a bunch of 64 bit constants like the ZPCI_*_ADDR
> which need a trailing "ULL", and also some with a "UL" which
> should probably be "ULL". For instance in
> 
> #define ZPCI_STE_FLAG_MASK      0x7ffUL
> #define ZPCI_STE_ADDR_MASK      (~ZPCI_STE_FLAG_MASK)
> 
> though ZPCI_STE_FLAG_MASK is OK by itself, when you use it
> in ZPCI_STE_ADDR_MASK you will get the logical-negate done
> at 32 bits before zero-extend to 64 bits, rather than a 64
> bit negate.
> 
> (I think that "UL" is almost never correct in QEMU -- you
> either want "at least 32 bits", in which case "U" is
> sufficient, or you need "64 bits", in which case you need
> "ULL".)

That's probably also an artifact of grabbing the constants from Linux
(where the code is 64 bit only).

> 
> Some of those suffixes are provoking compiler warnings or
> errors below, but some of them will just be silent wrong
> behaviour, so you should probably eyeball the #defines...

There are also some possibly dodgy places in non-pci code; I'll take a
look at those as well.