On Thu, Jul 23, 2020 at 09:02:09AM +0200, Jan Kiszka wrote: > 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?
Sounds good.
signature.asc
Description: PGP signature
