On Tue, May 28, 2013 at 12:15:16PM -0500, Anthony Liguori wrote: > > @@ -455,6 +462,226 @@ static void virtio_pci_config_write(void *opaque, > > hwaddr addr, > > } > > } > > > > +static uint64_t virtio_pci_config_common_read(void *opaque, hwaddr addr, > > + unsigned size) > > +{ > > + VirtIOPCIProxy *proxy = opaque; > > + VirtIODevice *vdev = proxy->vdev; > > + > > + uint64_t low = 0xffffffffull; > > + > > + switch (addr) { > > + case offsetof(struct virtio_pci_common_cfg, device_feature_select): > > + return proxy->device_feature_select; > > Oh dear no... Please use defines like the rest of QEMU.
Any good reason not to use offsetof? I see about 138 examples in qemu. Anyway, that's the way Rusty wrote it in the kernel header - I started with defines. If you convince Rusty to switch I can switch too, but I prefer reusing same structures as linux even if for now I've given up on reusing same headers. > >From a QEMU pov, take a look at: > > https://github.com/aliguori/qemu/commit/587c35c1a3fe90f6af0f97927047ef4d3182a659 > > And: > > https://github.com/aliguori/qemu/commit/01ba80a23cf2eb1e15056f82b44b94ec381565cb > > Which lets virtio-pci be subclassable and then remaps the config space to > BAR2. Interesting. Have the spec anywhere? You are saying this is going to conflict because of BAR2 usage, yes? So let's only do this virtio-fb only for new layout, so we don't need to maintain compatibility. In particular, we are working on making memory BAR access fast for virtio devices in a generic way. At the moment they are measureably slower than PIO on x86. > Haven't looked at the proposed new ring layout yet. > > Regards, No new ring layout. It's new config layout. -- MST _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization