[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [RFC] ivshmem v2: Shared memory device specification
On 23.07.20 08:54, Stefan Hajnoczi wrote:
On Fri, Jul 17, 2020 at 06:15:58PM +0200, Jan Kiszka wrote:On 15.07.20 15:27, Stefan Hajnoczi wrote:On Mon, May 25, 2020 at 09:58:28AM +0200, Jan Kiszka wrote:Thanks for the responses. It would be great to update the spec with these clarifications.If BAR 2 is not present, the shared memory region is not relocatable by the user. In that case, the hypervisor has to implement the Base Address register in the vendor-specific capability.What does relocatable mean in this context?That the guest can decide (via BAR) where the resource should show up in the physical guest address space. We do not want to support this in setups like for static partitioning hypervisors, and then we use that side-channel read-only configuration.I see. I'm not sure what is vendor-specific about non-relocatable shared memory. I guess it could be added to the spec too?
That "vendor-specific" comes from the PCI spec which - to my understanding - provides us no other means to introduce registers to the config space that are outside of the PCI spec. I could introduce a name for the ivshmem vendor cap and use that name here - would that be better?
In any case, since "relocatable" hasn't been fully defined, I suggest making the statement more general: If BAR 2 is not present the hypervisor has to implement the Base Address Register in the vendor-specific capability. This can be used for vendor-specific shared memory functionality.
Will integrate this. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]