Re: [virtio-comment] Re: [RFC] ivshmem v2: Shared memory device specification

[Jan Kiszka <jan.kiszka@siemens.com>]

On 27.07.20 15:20, Michael S. Tsirkin wrote:
> On Mon, May 25, 2020 at 09:58:28AM +0200, Jan Kiszka wrote:
> > #### Vendor Specific Capability (ID 09h)
> >
> > This capability must always be present.
> >
> > | Offset | Register            | Content                                        |
> > |-------:|:--------------------|:-----------------------------------------------|
> > |    00h | ID                  | 09h                                            |
> > |    01h | Next Capability     | Pointer to next capability or 00h              |
> > |    02h | Length              | 20h if Base Address is present, 18h otherwise  |
> > |    03h | Privileged Control  | Bit 0 (read/write): one-shot interrupt mode    |
> > |        |                     | Bits 1-7: Reserved (0 on read, writes ignored) |
> > |    04h | State Table Size    | 32-bit size of read-only State Table           |
> > |    08h | R/W Section Size    | 64-bit size of common read/write section       |
> > |    10h | Output Section Size | 64-bit size of output sections                 |
> > |    18h | Base Address        | optional: 64-bit base address of shared memory |
> >
> > All registers are read-only. Writes are ignored, except to bit 0 of
> > the Privileged Control register.
>
>
> Is there value in making this follow the virtio vendor-specific
> capability format? That will cost several extra bytes - do you envision
> having many of these in the config space?

Of course, this could be modeled with via virtio_pci_cap as well. Would 
add 12 unused by bytes and one type byte. If it helps to make the device 
look more virtio'ish, but I'm afraid there are more differences at PCI 
level.

I do not see a use case for having multiple of those caps above per 
device. If someone comes around with a valid use case for having 
multiple, non-consequitive shared memory regions for one device, we 
would need to add registers for them. But that would also only work for 
non-BAR regions due to limited BARs.

> Also, do we want to define an extended capability format in case this
> is a pci extended capability?

What would be the practical benefit? Do you see PCIe caps that could 
become useful in virtual setups? We don't do that for regular virtio 
devices either, do we?

Thanks,
Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux