qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: Re: [virtio-comment] Re: [RFC] ivshmem v2: Shared memory device specification
Date: Mon, 27 Jul 2020 15:39:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]