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/disagree.
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 out in practice because
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
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 accessor
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 out in practice because
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
