qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] s390: implement pci instructions


From: Frank Blaschka
Subject: Re: [Qemu-devel] [PATCH 2/3] s390: implement pci instructions
Date: Wed, 12 Nov 2014 15:34:35 +0100
User-agent: Mutt/1.5.17 (2007-11-01)

On Wed, Nov 12, 2014 at 10:36:03AM +0100, Paolo Bonzini wrote:
> 
> 
> On 12/11/2014 10:22, Alexander Graf wrote:
> >>>> Absolutely lets make an example for qemu running on BE and LE
> >>>>
> >>>> byte order    config space backing   pci_default_read_config   pcilg 
> >>>> (with cpu_to_le)
> >>>> BE            0x78563412             0x12345678                0x78563412
> >>>> LE            0x78563412             0x78563412                0x78563412
> >>>
> >>> No, pci_default_read_config() always returns 0x12345678 because it
> >>> returns a register, not memory.
> >>>
> >>
> >> You mean implementation of pci_default_read_config is broken?
> >> If it should return a register it should not do "return le32_to_cpu(val);"
> > 
> > It has to, to convert from memory (after memcpy) to an actual register
> > value. Look at the value list in Paolo's email - I really have no idea
> > how to explain it any better.
> 
> pci_default_read_config is reading from a *device* register, and has
> absolutely zero knowledge of the host CPU endianness.
> 
> Another way to explain that the result of pci_default_read_config is
> independent of the host endianness, is that the function is basically
> doing this:
> 
> switch (len) {
>     case 1: return d->config[address];
>     case 2: return ldw_le_p(&d->config[address)]);
>     case 4: return ldl_le_p(&d->config[address)]);
>     default: abort();
> }
> 
> So if you want to make the outcome big endian, you have to swap
> unconditionally.
> 
> Paolo

Hi Paolo, Alex,

thx a lot for all the explanation and patience.
I think I have understand your point now. I will change the code to 
unconditional swap. I feel I had a knowledge gap regarding running guest and
host which different byte orders. Hope this gap is filled now ;)

Frank

> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]