search for: virtio_pci_cfg_feature_sel

..._feature_select; > > Oh dear no... Please use defines like the rest of QEMU. It is pretty ugly. Yet the structure definitions are descriptive, capturing layout, size and endianness in natural a format readable by any C programmer. So AFAICT the question is, do we put the required #define VIRTIO_PCI_CFG_FEATURE_SEL \ (offsetof(struct virtio_pci_common_cfg, device_feature_select)) etc. in the kernel headers or qemu? > Haven't looked at the proposed new ring layout yet. No change, but there's an open question on whether we should nail it to little endian (or define the endian by the trans...

..._feature_select; > > Oh dear no... Please use defines like the rest of QEMU. It is pretty ugly. Yet the structure definitions are descriptive, capturing layout, size and endianness in natural a format readable by any C programmer. So AFAICT the question is, do we put the required #define VIRTIO_PCI_CFG_FEATURE_SEL \ (offsetof(struct virtio_pci_common_cfg, device_feature_select)) etc. in the kernel headers or qemu? > Haven't looked at the proposed new ring layout yet. No change, but there's an open question on whether we should nail it to little endian (or define the endian by the trans...

...ow the structure is used elsewhere. This may not be a problem for virtio because we all understand that the structures are part of an ABI, but if we used this pattern more in QEMU, it would be a lot less obvious. > So AFAICT the question is, do we put the required > > #define VIRTIO_PCI_CFG_FEATURE_SEL \ > (offsetof(struct virtio_pci_common_cfg, device_feature_select)) > > etc. in the kernel headers or qemu? I'm pretty sure we would end up just having our own integer defines. We carry our own virtio headers today because we can't easily import the kernel headers. >...

...ase use defines like the rest of QEMU. > > It is pretty ugly. > > Yet the structure definitions are descriptive, capturing layout, size > and endianness in natural a format readable by any C programmer. > > So AFAICT the question is, do we put the required > > #define VIRTIO_PCI_CFG_FEATURE_SEL \ > (offsetof(struct virtio_pci_common_cfg, device_feature_select)) > > etc. in the kernel headers or qemu? I forgot that we need to validate size (different fields have different sizes so memory core does not validate for us). And that is much cleaner if we use offsetof direc...

...blem for virtio because we all understand that > the structures are part of an ABI, but if we used this pattern more > in QEMU, it would be a lot less obvious. So let's not use it more in QEMU. > > So AFAICT the question is, do we put the required > > > > #define VIRTIO_PCI_CFG_FEATURE_SEL \ > > (offsetof(struct virtio_pci_common_cfg, device_feature_select)) > > > > etc. in the kernel headers or qemu? > > I'm pretty sure we would end up just having our own integer defines. We > carry our own virtio headers today because we can't easily im...

This adds support for new config, and is designed to work with the new layout code in Rusty's new layout branch. At the moment all fields are in the same memory BAR (bar 2). This will be used to test performance and compare memory, io and hypercall latency. Compiles but does not work yet. Migration isn't handled yet. It's not clear what do queue_enable/queue_disable fields do, not

This adds support for new config, and is designed to work with the new layout code in Rusty's new layout branch. At the moment all fields are in the same memory BAR (bar 2). This will be used to test performance and compare memory, io and hypercall latency. Compiles but does not work yet. Migration isn't handled yet. It's not clear what do queue_enable/queue_disable fields do, not