<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>40bcdb12 - vfio/virtio: Enable live migration once VIRTIO_PCI was configured</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/vfio/pci/virtio/Makefile#40bcdb12</link>
        <description>vfio/virtio: Enable live migration once VIRTIO_PCI was configuredNow that the driver supports live migration, only the legacy IOfunctionality depends on config VIRTIO_PCI_ADMIN_LEGACY.As part of that we introduce a bool configuration option as a sub menuunder the driver&apos;s main live migration feature namedVIRTIO_VFIO_PCI_ADMIN_LEGACY, to control the legacy IO functionality.This will let users configuring the kernel, know which features from thedescription might be available in the resulting driver.As of that, move the legacy IO into a separate file to be compiled onlyonce CONFIG_VIRTIO_VFIO_PCI_ADMIN_LEGACY was configured and let the livemigration depends only on VIRTIO_PCI.Signed-off-by: Yishai Hadas &lt;yishaih@nvidia.com&gt;Link: https://lore.kernel.org/r/20241113115200.209269-8-yishaih@nvidia.comSigned-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;

            List of files:
            /linux-6.15/drivers/vfio/pci/virtio/Makefile</description>
        <pubDate>Wed, 13 Nov 2024 11:52:00 +0000</pubDate>
        <dc:creator>Yishai Hadas &lt;yishaih@nvidia.com&gt;</dc:creator>
    </item>
<item>
        <title>0bbc82e4 - vfio/virtio: Add support for the basic live migration functionality</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/vfio/pci/virtio/Makefile#0bbc82e4</link>
        <description>vfio/virtio: Add support for the basic live migration functionalityAdd support for basic live migration functionality in VFIO overvirtio-net devices, aligned with the virtio device specification 1.4.This includes the following VFIO features:VFIO_MIGRATION_STOP_COPY, VFIO_MIGRATION_P2P.The implementation registers with the VFIO subsystem using vfio_pci_coreand then incorporates the virtio-specific logic for the migrationprocess.The migration follows the definitions in uapi/vfio.h and leverages thevirtio VF-to-PF admin queue command channel for execution device partsrelated commands.Additional Notes:-----------------The kernel protocol between the source and target devices contains aheader with metadata, including record size, tag, and flags.The record size allows the target to recognize and read a complete imagefrom the source before passing the device part data. This adheres to thevirtio device specification, which mandates that partial device partscannot be supplied.The tag and flags serve as placeholders for future extensions of thekernel protocol between the source and target, ensuring backward andforward compatibility.Both the source and target comply with the virtio device specificationby using a device part object with a unique ID as part of the migrationprocess. Since this resource is limited to a maximum of 255, itslifecycle is confined to periods with an active live migration flow.According to the virtio specification, a device has only two modes:RUNNING and STOPPED. As a result, certain VFIO transitions (i.e.,RUNNING_P2P-&gt;STOP, STOP-&gt;RUNNING_P2P) are treated as no-ops. Whentransitioning to RUNNING_P2P, the device state is set to STOP, and itwill remain STOPPED until the transition out of RUNNING_P2P-&gt;RUNNING, atwhich point it returns to RUNNING. During transition to STOP, the virtiodevice only stops initiating outgoing requests(e.g. DMA, MSIx, etc.) butstill must accept incoming operations.Signed-off-by: Yishai Hadas &lt;yishaih@nvidia.com&gt;Link: https://lore.kernel.org/r/20241113115200.209269-6-yishaih@nvidia.comSigned-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;

            List of files:
            /linux-6.15/drivers/vfio/pci/virtio/Makefile</description>
        <pubDate>Wed, 13 Nov 2024 11:51:58 +0000</pubDate>
        <dc:creator>Yishai Hadas &lt;yishaih@nvidia.com&gt;</dc:creator>
    </item>
<item>
        <title>eb61eca0 - vfio/virtio: Introduce a vfio driver over virtio devices</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/vfio/pci/virtio/Makefile#eb61eca0</link>
        <description>vfio/virtio: Introduce a vfio driver over virtio devicesIntroduce a vfio driver over virtio devices to support the legacyinterface functionality for VFs.Background, from the virtio spec [1].--------------------------------------------------------------------In some systems, there is a need to support a virtio legacy driver witha device that does not directly support the legacy interface. In suchscenarios, a group owner device can provide the legacy interfacefunctionality for the group member devices. The driver of the ownerdevice can then access the legacy interface of a member device on behalfof the legacy member device driver.For example, with the SR-IOV group type, group members (VFs) can notpresent the legacy interface in an I/O BAR in BAR0 as expected by thelegacy pci driver. If the legacy driver is running inside a virtualmachine, the hypervisor executing the virtual machine can present avirtual device with an I/O BAR in BAR0. The hypervisor intercepts thelegacy driver accesses to this I/O BAR and forwards them to the groupowner device (PF) using group administration commands.--------------------------------------------------------------------Specifically, this driver adds support for a virtio-net VF to be exposedas a transitional device to a guest driver and allows the legacy IO BARfunctionality on top.This allows a VM which uses a legacy virtio-net driver in the guest towork transparently over a VF which its driver in the host is that newdriver.The driver can be extended easily to support some other types of virtiodevices (e.g virtio-blk), by adding in a few places the specific typeproperties as was done for virtio-net.For now, only the virtio-net use case was tested and as such we introducethe support only for such a device.Practically,Upon probing a VF for a virtio-net device, in case its PF supportslegacy access over the virtio admin commands and the VF doesn&apos;t have BAR0, we set some specific &apos;vfio_device_ops&apos; to be able to simulate in SW atransitional device with I/O BAR in BAR 0.The existence of the simulated I/O bar is reported later on byoverwriting the VFIO_DEVICE_GET_REGION_INFO command and the deviceexposes itself as a transitional device by overwriting some propertiesupon reading its config space.Once we report the existence of I/O BAR as BAR 0 a legacy driver in theguest may use it via read/write calls according to the virtiospecification.Any read/write towards the control parts of the BAR will be captured bythe new driver and will be translated into admin commands towards thedevice.In addition, any data path read/write access (i.e. virtio drivernotifications) will be captured by the driver and forwarded to thephysical BAR which its properties were supplied by the admin commandVIRTIO_ADMIN_CMD_LEGACY_NOTIFY_INFO upon the probing/init flow.With that code in place a legacy driver in the guest has the look andfeel as if having a transitional device with legacy support for both itscontrol and data path flows.[1]https://github.com/oasis-tcs/virtio-spec/commit/03c2d32e5093ca9f2a17797242fbef88efe94b8cReviewed-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;Reviewed-by: Kevin Tian &lt;kevin.tian@intel.com&gt;Signed-off-by: Yishai Hadas &lt;yishaih@nvidia.com&gt;Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;Link: https://lore.kernel.org/r/20231219093247.170936-10-yishaih@nvidia.comSigned-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;

            List of files:
            /linux-6.15/drivers/vfio/pci/virtio/Makefile</description>
        <pubDate>Tue, 19 Dec 2023 09:32:47 +0000</pubDate>
        <dc:creator>Yishai Hadas &lt;yishaih@nvidia.com&gt;</dc:creator>
    </item>
</channel>
</rss>
