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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

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


Subject: Re: [virtio] [PATCH v10 04/10] admin: introduce virtio admin virtqueues


On Tue, Mar 07, 2023 at 08:36:41AM +0100, Jiri Pirko wrote:
> Hmm, if not for now, the future exension would not be so simple, I fear.

Without knowing what it is I can't say.

> 
> >
> >Passing commands to devices themselves is already covered in spec
> >reasonably well though not in a generic way.
> 
> You mean using the control queue, correct?

Depends on the device type. network devices have a control queue, yes.

> >From one of the patch description of this patchset I understand that you
> cannot use control queue for this because control queue is
> device-specific, yet group control is device-agnostic.
> 
> My undestanding therefore was, that the admin queue you are introducing
> serves as a generic carrier for device-agnostic commands, in parallel
> for having control queue serving as a generic carrier of device-specific
> commands. If this is not the case, I think it would be nice to describe
> the exact monivation and scope of admin queue.

Nope unfortunately.  This queue is just a carrier for admin commands.
admin commands are commands that talk to one device about other
devices. There's clearly no mechanism in the spec to do that,
so we plug this hole.



> 
> >
> >What we lack is passing commands about one device to another device.
> >E.g. control VFs through PFs.
> 
> Could you provide examples of such commands please?

For example a common feature is to program a vlan and have device
put a given VF inside this vlan.

In a virtualization scenario host controls this vlan programming giving
the network a measure of protection from VFs.  If a VF is passed through
to a VM, IOMMU limits VFs to only access guest memory so host has to do
this programming through a PF.



> 
> >This is what groups do.
> >But if we see more uses we can always add them.
> >
> >
> >I'd rather avoid being too generic though.
> 
> In that case, why not to avoid using generic terms and stay
> "group-centric"? What I mean is:
> "Administration Virtqueues" -> "Group Administration Virtqueues"
> "struct virtio_admin_cmd" -> "struct virtio_group_admin_cmd"
> 
> Etc. Helps to avoid confusion.

Sure, I tried to do that but missed some opportunities.
Will address.

> 
> >
> >
> >
> >
> >> 
> >> >+than one administration virtqueue.
> 
> 
> [...]
> 



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