Displaying 7 results from an estimated 7 matches for "virtio_pci_cfg_feature_sel".
2013 May 29
6
[PATCH RFC] virtio-pci: new config layout: using memory BAR
..._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...
2013 May 29
6
[PATCH RFC] virtio-pci: new config layout: using memory BAR
..._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...
2013 May 29
0
[PATCH RFC] virtio-pci: new config layout: using memory BAR
...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.
>...
2013 May 29
0
[PATCH RFC] virtio-pci: new config layout: using memory BAR
...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...
2013 May 29
7
[PATCH RFC] virtio-pci: new config layout: using memory BAR
...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...
2013 May 28
3
[PATCH RFC] virtio-pci: new config layout: using memory BAR
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
2013 May 28
3
[PATCH RFC] virtio-pci: new config layout: using memory BAR
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