On 03/24/2013 01:19 PM, Michael S. Tsirkin wrote:
>> struct virtio_pci_cap {
>> u8 cap_vndr; /* Generic PCI field: PCI_CAP_ID_VNDR */
>> @@ -150,7 +153,9 @@ struct virtio_pci_common_cfg {
>> __le16 queue_size; /* read-write, power of 2. */
>> __le16 queue_msix_vector;/* read-write */
>> __le16 queue_enable; /* read-write */
>> - __le16 queue_notify; /* read-only */
>> + __le16 unused2;
>> + __le32 queue_notify_val;/* read-only */
>> + __le32 queue_notify_off;/* read-only */
>> __le64 queue_desc; /* read-write */
>> __le64 queue_avail; /* read-write */
>> __le64 queue_used; /* read-write */
>
> So how exactly do the offsets mesh with the dual capability? For IO we
> want to use the same address and get queue from the data, for memory we
> want a per queue address ...
>
How about having a readonly field which is "address increment per trigger"?
The guest would be required to always write the queue number as the
data, however, the host would not be required to interpret it if the
address increment is nonzero?
-hpa
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
