[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 14/25] spapr: push the XIVE EQ data in OS event
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-devel] [PATCH 14/25] spapr: push the XIVE EQ data in OS event queue |
Date: |
Tue, 5 Dec 2017 10:58:23 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 12/04/2017 01:20 AM, David Gibson wrote:
> On Sat, Dec 02, 2017 at 08:46:19AM -0600, Benjamin Herrenschmidt wrote:
>> On Sat, 2017-12-02 at 08:45 -0600, Benjamin Herrenschmidt wrote:
>>> On Fri, 2017-12-01 at 15:10 +1100, David Gibson wrote:
>>>>
>>>> Hm, ok. Guest endian (or at least, not definitively host-endian) data
>>>> in a plain uint32_t makes me uncomfortable. Could we use char data[4]
>>>> instead, to make it clear it's a byte-ordered buffer, rather than a
>>>> number as far as the XIVE is concerned.
>>>>
>>>> Hm.. except that doesn't quite work, because the hardware must define
>>>> which end that generation bit ends up in...
>>>
>>> It also needs to be written atomically. Just say it's big endian.
>>
>> Also the guest reads it using be32_to_cpup...
>
> Ok. Definitely should be treated as BE and read/written with the be32
> DMA helper functions.
>
hmm, the stl_be_dma does not return errors but dma_memory_write()
does.
static inline void st##_sname##_##_end##_dma(AddressSpace *as, \
dma_addr_t addr, \
uint##_bits##_t val) \
{ \
val = cpu_to_##_end##_bits(val); \
dma_memory_write(as, addr, &val, (_bits) / 8); \
}
These macros seem to be only used by spapr_vio and nvram. I can probably
change them.
C.