Anthony Liguori wrote:
> I converted everything to use offsetof but left the accessors. You need
> a fair number of macros to handle the various data sizes and even then,
> I think it ends up looking nicer with the macros. See my patch series
> on qemu-devel and let me know if you agree/disagr
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>>> #define s_ld_u64(phys, field, type) \
>>> ldq_phys(phys + offsetof(field, type))
>>>
>>>
>>> And now we don't need individual accessors, or to encode the offsets
>>> as magic numbers.
>>>
>> It's a nice thought but it doesn't work ou
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>>> #define s_ld_u64(phys, field, type) \
>>> ldq_phys(phys + offsetof(field, type))
>>>
>>>
>>> And now we don't need individual accessors, or to encode the offsets
>>> as magic numbers.
>>>
>> It's a nice thought but it doesn't work ou
Anthony Liguori wrote:
>>
>> #define s_ld_u64(phys, field, type) \
>> ldq_phys(phys + offsetof(field, type))
>>
>>
>> And now we don't need individual accessors, or to encode the offsets
>> as magic numbers.
>
> It's a nice thought but it doesn't work out in practice because most
> of these
Avi Kivity wrote:
>
> I don't think a full blown dma api is that horrible. You need a
> function that translates a phys vectors to iovecs. A slight
> complication is that the vectors can be of different sizes, but it's
> still not that bad.
Yeah, I've already started on that. One of the pro
Anthony Liguori wrote:
> virtio is currently pretty sloppy about accessing guest memory directly. This
> is problematic both because phys_ram_base + PA is not only valid but also
> because it requires the host and guest both be of the same endianness.
>
> This patch converts virtio to use the QEMU
virtio is currently pretty sloppy about accessing guest memory directly. This
is problematic both because phys_ram_base + PA is not only valid but also
because it requires the host and guest both be of the same endianness.
This patch converts virtio to use the QEMU st/ld functions to manipulate t
