qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Hajnoczi
Subject: Re: [virtio-comment] [RFC] ivshmem v2: Shared memory device specification
Date: Mon, 27 Jul 2020 13:29:39 +0100

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.

Attachment: signature.asc
Description: PGP signature


reply via email to

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