OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] [PATCH 1/3] shared memory: Define shared memory regions


On Fri, 11 Jan 2019 18:57:17 +0100
Halil Pasic <pasic@linux.ibm.com> wrote:

> On Fri, 11 Jan 2019 16:07:23 +0000
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> 
> > > Do we want to change the device initialization (3.1) subsection? I'm not
> > > sure if this shared  memory region discovery is something that's
> > > supposed to be a part of the initialization. At the moment, I would guess
> > > is the device not supposed to be able to provide new regions at any time
> > > (as I don't see how the device is supposed to tell the driver: hey
> > > please re-do discovery).     
> > 
> > Yes, it's part of initialisation; although since the enumeration is
> > specific to the transport and the use is specific to the device, I'm not
> > sure what goes in a common initialization section.  
> 
> I think it does go in a common initialization. Virtqueues are also
> discovered in a transport specific way, and same goes for reading/writing config.
> 
> So I would add somethng to 
> "7. Perform device-specific setup, including discovery of virtqueues for
> the device, optional per-bus setup, reading and possibly writing the
> deviceâs virtio configuration space, and population of virtqueues." in
> subsection 3.1.1.

Agreed, it probably makes sense to add shared memory region discovery
as an extra item to this list of things to be setup.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]