[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: virtio member device provisioning get/set and virtio child device life cycle mixing not needed
On 6/28/2023 9:10 PM, Parav Pandit wrote:
It is the guest to config MSIX of an assigned VF by writing to MSIX capability. However host owns the AQ,From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis- open.org> On Behalf Of Zhu, Lingshan Sent: Wednesday, June 28, 2023 3:31 AM On 6/28/2023 8:22 AM, Parav Pandit wrote:Hi Lingshan Zhu, I have reviewed v4 version transport VQ a while back that consist of two mainpieces.1. some virtio device creation/destroy commands 2. virtio device feature and config space provisioning commands. Many of us are seeing the value of device provisioning commandswith/without live migration.New virtio devices do not need to follow any existing of config space etc persay for real hw.There is some value in reusing software but it may not be the prime drivingfactor for brand new devices.This needs more discussion and not as_is done in the v4. So, if you are planning to revise your transport vq patches as admincommands, please split the series into two.a. device and config space provisioning SET/GET part.Hi Parav I agree it is good to unify the interface for SRIOV and SIOV. However more discussion is required, e.g., for a VF, will config its MSIX by admin vq(owned by host) conflict with the MSIX cap.No, it doesn't conflict. SR-PCIM interface is outside the scope of PCIe spec. I completed the work in PCI spec to clarify this already, its coming in the 6.1 errata spec. Non virtio device and Linux kernel both already has similar implementation in place and in use for more than a year. So msix provisioning via AQ is fine. VF can expose new MSIX capability post reconfiguration via AQ.
means host can modify the MSIX config even when guest operational running.A new synchronization mechanism? Trap accesses to MSIX cap? Ban access of MSIX through AQ after DRIVER_OK? Do you have any detailed information about how to prevent the conflicts like this?
We will be able to unify them across SRIOV and SIOV. SIOV anyway has to wait as its undergoing significant changes currently.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]