<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://linux-kvm.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Jensfr</id>
	<title>KVM - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://linux-kvm.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Jensfr"/>
	<link rel="alternate" type="text/html" href="https://linux-kvm.org/page/Special:Contributions/Jensfr"/>
	<updated>2026-05-21T03:20:06Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.39.5</generator>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173995</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173995"/>
		<updated>2019-04-03T14:31:46Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst or in https://www.kernel.org/doc/html/latest/networking/net_failover.html&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device still has a lot of open questions.&lt;br /&gt;
&lt;br /&gt;
What is currently explored are two ways of orchestrating datapath switching in case of (for example) a migration.&lt;br /&gt;
&lt;br /&gt;
1. A way that tries to encapsulate the mechanism in qemu/host and avoids involving the management layer.  mark the virtio device in qemu as hidden if specified on qemu cmdline. save the virtio-net device cmdline params for later. virtio device is &#039;unhidden&#039; when VIRTIO_NET_F_STANDBY feature is negotiated. This is for automatic hot-plugging and datapath switching (in host kernel).&lt;br /&gt;
&lt;br /&gt;
2. Another way is to involve the management layer. Oracle has posted patches for QEMU: https://patchwork.kernel.org/cover/10721503/&lt;br /&gt;
This patch set introduces two new events, 1. is emitted when the VIRTIO_NET_F_STANDBY features is negotiated, 2. is emitted when the virtio_net driver is removed (manually or during a reboot). It also remove vfio devices from guest during reboot which are markes with x-failover-primary flag. &lt;br /&gt;
&lt;br /&gt;
=== How does netvsc do failover and migration ===&lt;br /&gt;
The netvsc driver doesn&#039;t use the net_failover module. In fact it was&lt;br /&gt;
written before net_failover existed. It does have very similar features&lt;br /&gt;
though, built-in to the netvsc driver itself. It uses a 2-device model, meaning it creates a&lt;br /&gt;
logical device, the netvsc device and manages VF&lt;br /&gt;
devices as they are hot-plugged. As a new VF device is detected it is&lt;br /&gt;
grabbed and made a slave of the corresponding netvsc device. The VF device is usually &lt;br /&gt;
renamed by udev and gets a persistant name. It is also marked with the &lt;br /&gt;
IFF_SLAVE flag so that networking tools that are smart enough can recognize &lt;br /&gt;
the connection between netvsc and VF device. &lt;br /&gt;
&lt;br /&gt;
Matching netvsc and VF device: Here a different approach to net_failover is taken. When a new VF device is hotplugged finding the corresponding netvsc device is done by finding one with the same serial number. The VMBus API provides a serial number that is used for matching the devices. Hyperv pci controller saves the ID as the PCI slot name.&lt;br /&gt;
&lt;br /&gt;
During creation/initialization of the netvsc device the slower VMBUS&lt;br /&gt;
channel is set up as data-path called synthetic data-path. When   &lt;br /&gt;
the netvsc driver enslaves the VF device &lt;br /&gt;
the datapath is now switched over to it. For switching the data-path a VMBUS message is sent to the&lt;br /&gt;
hypervisor which takes care of re-programming the NIC internal switch.&lt;br /&gt;
           &lt;br /&gt;
The failover data-path is a VMBUS channel. It is switched to when the VF&lt;br /&gt;
device is unplugged or becomes malfunctioning.   &lt;br /&gt;
&lt;br /&gt;
For the user the bond between the two devices is transparent. The netvsc&lt;br /&gt;
device is created and becomes the interface over which 1. all traffic is&lt;br /&gt;
routed and 2. all configuration is done to. When a VF device is hotplugged&lt;br /&gt;
the data-path will be automatically fast and on &lt;br /&gt;
failure/initializtion/shutdown/migration the driver switches to the slower &lt;br /&gt;
VMBUS channel.&lt;br /&gt;
&lt;br /&gt;
(change from device matching via MAC to serial ID: &lt;br /&gt;
commit 00d7ddba1143623b31bc2c15d18216e2da031b14&lt;br /&gt;
Author: Stephen Hemminger &amp;lt;stephen@networkplumber.org&amp;gt;&lt;br /&gt;
Date:   Fri Sep 14 12:54:57 2018 -0700&lt;br /&gt;
&lt;br /&gt;
    hv_netvsc: pair VF based on serial number&lt;br /&gt;
)&lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. &lt;br /&gt;
&lt;br /&gt;
Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
Status 2019-04-02: Code of tools is on https://github.com/jensfr/netfailover_driver_detect&lt;br /&gt;
&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;br /&gt;
# Other ways of marking two devices as standby/primary. Assigning identical MAC addresses could be problematic/confusing, e.g. what if more than two devices with identical MAC addresses show up. Which one to choose? Ideas for other ways to recognize devices that belong together:&lt;br /&gt;
## Assign an ID to both devices. Where to store the ID? PCI config space? -&amp;gt; no way to know what part of config space is unused.&lt;br /&gt;
## Put devices behind a PCI(e) bridge with a special device ID. The two devices on this bridge are supposed to form a failover/standby/primary device set.&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173994</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173994"/>
		<updated>2019-03-11T14:43:08Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* How does netvsc do failover and migration */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst or in https://www.kernel.org/doc/html/latest/networking/net_failover.html&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device still has a lot of open questions.&lt;br /&gt;
&lt;br /&gt;
What is currently explored are two ways of orchestrating datapath switching in case of (for example) a migration.&lt;br /&gt;
&lt;br /&gt;
1. A way that tries to encapsulate the mechanism in qemu/host and avoids involving the management layer.  mark the virtio device in qemu as hidden if specified on qemu cmdline. save the virtio-net device cmdline params for later. virtio device is &#039;unhidden&#039; when VIRTIO_NET_F_STANDBY feature is negotiated. This is for automatic hot-plugging and datapath switching (in host kernel).&lt;br /&gt;
&lt;br /&gt;
2. Another way is to involve the management layer. Oracle has posted patches for QEMU: https://patchwork.kernel.org/cover/10721503/&lt;br /&gt;
This patch set introduces two new events, 1. is emitted when the VIRTIO_NET_F_STANDBY features is negotiated, 2. is emitted when the virtio_net driver is removed (manually or during a reboot). It also remove vfio devices from guest during reboot which are markes with x-failover-primary flag. &lt;br /&gt;
&lt;br /&gt;
=== How does netvsc do failover and migration ===&lt;br /&gt;
The netvsc driver doesn&#039;t use the net_failover module. In fact it was&lt;br /&gt;
written before net_failover existed. It does have very similar features&lt;br /&gt;
though, built-in to the netvsc driver itself. It uses a 2-device model, meaning it creates a&lt;br /&gt;
logical device, the netvsc device and manages VF&lt;br /&gt;
devices as they are hot-plugged. As a new VF device is detected it is&lt;br /&gt;
grabbed and made a slave of the corresponding netvsc device. The VF device is usually &lt;br /&gt;
renamed by udev and gets a persistant name. It is also marked with the &lt;br /&gt;
IFF_SLAVE flag so that networking tools that are smart enough can recognize &lt;br /&gt;
the connection between netvsc and VF device. &lt;br /&gt;
&lt;br /&gt;
Matching netvsc and VF device: Here a different approach to net_failover is taken. When a new VF device is hotplugged finding the corresponding netvsc device is done by finding one with the same serial number. The VMBus API provides a serial number that is used for matching the devices. Hyperv pci controller saves the ID as the PCI slot name.&lt;br /&gt;
&lt;br /&gt;
During creation/initialization of the netvsc device the slower VMBUS&lt;br /&gt;
channel is set up as data-path called synthetic data-path. When   &lt;br /&gt;
the netvsc driver enslaves the VF device &lt;br /&gt;
the datapath is now switched over to it. For switching the data-path a VMBUS message is sent to the&lt;br /&gt;
hypervisor which takes care of re-programming the NIC internal switch.&lt;br /&gt;
           &lt;br /&gt;
The failover data-path is a VMBUS channel. It is switched to when the VF&lt;br /&gt;
device is unplugged or becomes malfunctioning.   &lt;br /&gt;
&lt;br /&gt;
For the user the bond between the two devices is transparent. The netvsc&lt;br /&gt;
device is created and becomes the interface over which 1. all traffic is&lt;br /&gt;
routed and 2. all configuration is done to. When a VF device is hotplugged&lt;br /&gt;
the data-path will be automatically fast and on &lt;br /&gt;
failure/initializtion/shutdown/migration the driver switches to the slower &lt;br /&gt;
VMBUS channel.&lt;br /&gt;
&lt;br /&gt;
(change from device matching via MAC to serial ID: &lt;br /&gt;
commit 00d7ddba1143623b31bc2c15d18216e2da031b14&lt;br /&gt;
Author: Stephen Hemminger &amp;lt;stephen@networkplumber.org&amp;gt;&lt;br /&gt;
Date:   Fri Sep 14 12:54:57 2018 -0700&lt;br /&gt;
&lt;br /&gt;
    hv_netvsc: pair VF based on serial number&lt;br /&gt;
)&lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;br /&gt;
# Other ways of marking two devices as standby/primary. Assigning identical MAC addresses could be problematic/confusing, e.g. what if more than two devices with identical MAC addresses show up. Which one to choose? Ideas for other ways to recognize devices that belong together:&lt;br /&gt;
## Assign an ID to both devices. Where to store the ID? PCI config space? -&amp;gt; no way to know what part of config space is unused.&lt;br /&gt;
## Put devices behind a PCI(e) bridge with a special device ID. The two devices on this bridge are supposed to form a failover/standby/primary device set.&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173993</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173993"/>
		<updated>2019-03-07T09:30:28Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* How does netvsc do failover and migration */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst or in https://www.kernel.org/doc/html/latest/networking/net_failover.html&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device still has a lot of open questions.&lt;br /&gt;
&lt;br /&gt;
What is currently explored are two ways of orchestrating datapath switching in case of (for example) a migration.&lt;br /&gt;
&lt;br /&gt;
1. A way that tries to encapsulate the mechanism in qemu/host and avoids involving the management layer.  mark the virtio device in qemu as hidden if specified on qemu cmdline. save the virtio-net device cmdline params for later. virtio device is &#039;unhidden&#039; when VIRTIO_NET_F_STANDBY feature is negotiated. This is for automatic hot-plugging and datapath switching (in host kernel).&lt;br /&gt;
&lt;br /&gt;
2. Another way is to involve the management layer. Oracle has posted patches for QEMU: https://patchwork.kernel.org/cover/10721503/&lt;br /&gt;
This patch set introduces two new events, 1. is emitted when the VIRTIO_NET_F_STANDBY features is negotiated, 2. is emitted when the virtio_net driver is removed (manually or during a reboot). It also remove vfio devices from guest during reboot which are markes with x-failover-primary flag. &lt;br /&gt;
&lt;br /&gt;
=== How does netvsc do failover and migration ===&lt;br /&gt;
The netvsc driver doesn&#039;t use the net_failover module. In fact it was&lt;br /&gt;
written before net_failover existed. It does have very similar features&lt;br /&gt;
though, built-in to the netvsc driver itself. It creates a&lt;br /&gt;
logical device, the netvsc device and manages VF&lt;br /&gt;
devices as they are hot-plugged. As a new VF device is detected it is&lt;br /&gt;
grabbed and made a slave of the corresponding netvsc device. The VF device is usually &lt;br /&gt;
renamed by udev and gets a persistant name. It is also marked with the &lt;br /&gt;
IFF_SLAVE flag so that networking tools that are smart enough can recognize &lt;br /&gt;
the connection between netvsc and VF device. &lt;br /&gt;
&lt;br /&gt;
Matching netvsc and VF device: Here a different approach to net_failover is taken. When a new VF device is hotplugged finding the corresponding netvsc device is done by finding one with the same serial number. The VMBus API provides a serial number that is used for matching the devices. Hyperv pci controller saves the ID as the PCI slot name.&lt;br /&gt;
&lt;br /&gt;
During creation/initialization of the netvsc device the slower VMBUS&lt;br /&gt;
channel is set up as data-path called synthetic data-path. When   &lt;br /&gt;
the netvsc driver enslaves the VF device &lt;br /&gt;
the datapath is now switched over to it. For switching the data-path a VMBUS message is sent to the&lt;br /&gt;
hypervisor which takes care of re-programming the NIC internal switch.&lt;br /&gt;
           &lt;br /&gt;
The failover data-path is a VMBUS channel. It is switched to when the VF&lt;br /&gt;
device is unplugged or becomes malfunctioning.   &lt;br /&gt;
&lt;br /&gt;
For the user the bond between the two devices is transparent. The netvsc&lt;br /&gt;
device is created and becomes the interface over which 1. all traffic is&lt;br /&gt;
routed and 2. all configuration is done to. When a VF device is hotplugged&lt;br /&gt;
the data-path will be automatically fast and on &lt;br /&gt;
failure/initializtion/shutdown/migration the driver switches to the slower &lt;br /&gt;
VMBUS channel.&lt;br /&gt;
&lt;br /&gt;
(change from device matching via MAC to serial ID: &lt;br /&gt;
commit 00d7ddba1143623b31bc2c15d18216e2da031b14&lt;br /&gt;
Author: Stephen Hemminger &amp;lt;stephen@networkplumber.org&amp;gt;&lt;br /&gt;
Date:   Fri Sep 14 12:54:57 2018 -0700&lt;br /&gt;
&lt;br /&gt;
    hv_netvsc: pair VF based on serial number&lt;br /&gt;
)&lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;br /&gt;
# Other ways of marking two devices as standby/primary. Assigning identical MAC addresses could be problematic/confusing, e.g. what if more than two devices with identical MAC addresses show up. Which one to choose? Ideas for other ways to recognize devices that belong together:&lt;br /&gt;
## Assign an ID to both devices. Where to store the ID? PCI config space? -&amp;gt; no way to know what part of config space is unused.&lt;br /&gt;
## Put devices behind a PCI(e) bridge with a special device ID. The two devices on this bridge are supposed to form a failover/standby/primary device set.&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173992</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173992"/>
		<updated>2019-03-07T08:36:58Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* How does netvsc do failover and migration */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst or in https://www.kernel.org/doc/html/latest/networking/net_failover.html&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device still has a lot of open questions.&lt;br /&gt;
&lt;br /&gt;
What is currently explored are two ways of orchestrating datapath switching in case of (for example) a migration.&lt;br /&gt;
&lt;br /&gt;
1. A way that tries to encapsulate the mechanism in qemu/host and avoids involving the management layer.  mark the virtio device in qemu as hidden if specified on qemu cmdline. save the virtio-net device cmdline params for later. virtio device is &#039;unhidden&#039; when VIRTIO_NET_F_STANDBY feature is negotiated. This is for automatic hot-plugging and datapath switching (in host kernel).&lt;br /&gt;
&lt;br /&gt;
2. Another way is to involve the management layer. Oracle has posted patches for QEMU: https://patchwork.kernel.org/cover/10721503/&lt;br /&gt;
This patch set introduces two new events, 1. is emitted when the VIRTIO_NET_F_STANDBY features is negotiated, 2. is emitted when the virtio_net driver is removed (manually or during a reboot). It also remove vfio devices from guest during reboot which are markes with x-failover-primary flag. &lt;br /&gt;
&lt;br /&gt;
=== How does netvsc do failover and migration ===&lt;br /&gt;
The netvsc driver doesn&#039;t use the net_failover module. In fact it was&lt;br /&gt;
written before net_failover existed. It does have very similar features&lt;br /&gt;
though, built-in to the netvsc driver itself. It creates a&lt;br /&gt;
logical device, the netvsc device and manages VF&lt;br /&gt;
devices as they are hot-plugged. As a new VF device is detected it is&lt;br /&gt;
grabbed and made a slave of the netvsc device if the two devices have the same MAC address. The VF device is usually &lt;br /&gt;
renamed by udev and gets a persistant name. It is also marked with the &lt;br /&gt;
SLAVE flag so that networking tools that are smart enough can recognize &lt;br /&gt;
the connection between netvsc and VF device. &lt;br /&gt;
During creation/initialization of the netvsc device the slower VMBUS&lt;br /&gt;
channel is set up as data-path called synthetic data-path.&lt;br /&gt;
&lt;br /&gt;
At this point  &lt;br /&gt;
the netvsc driver enslaves the VF device and&lt;br /&gt;
the datapath is now switched over it. For switching the data-path a VMBUS message is sent to the&lt;br /&gt;
hypervisor which takes care of re-programming the NIC internal switch.&lt;br /&gt;
           &lt;br /&gt;
The failover data-path is a VMBUS channel. It is switched to when the VF&lt;br /&gt;
device is unplugged or becomes malfunctioning.   &lt;br /&gt;
&lt;br /&gt;
For the user the bond between the two devices is transparent. The netvsc&lt;br /&gt;
device is created and becomes the interface over which 1. all traffic is&lt;br /&gt;
routed and 2. all configuration is done to. When a VF device is hotplugged&lt;br /&gt;
the data-path will be automatically fast and on &lt;br /&gt;
failure/initializtion/shutdown/migration the driver switches to the slower &lt;br /&gt;
VMBUS channel.&lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;br /&gt;
# Other ways of marking two devices as standby/primary. Assigning identical MAC addresses could be problematic/confusing, e.g. what if more than two devices with identical MAC addresses show up. Which one to choose? Ideas for other ways to recognize devices that belong together:&lt;br /&gt;
## Assign an ID to both devices. Where to store the ID? PCI config space? -&amp;gt; no way to know what part of config space is unused.&lt;br /&gt;
## Put devices behind a PCI(e) bridge with a special device ID. The two devices on this bridge are supposed to form a failover/standby/primary device set.&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173991</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173991"/>
		<updated>2019-03-04T22:05:01Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst or in https://www.kernel.org/doc/html/latest/networking/net_failover.html&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device still has a lot of open questions.&lt;br /&gt;
&lt;br /&gt;
What is currently explored are two ways of orchestrating datapath switching in case of (for example) a migration.&lt;br /&gt;
&lt;br /&gt;
1. A way that tries to encapsulate the mechanism in qemu/host and avoids involving the management layer.  mark the virtio device in qemu as hidden if specified on qemu cmdline. save the virtio-net device cmdline params for later. virtio device is &#039;unhidden&#039; when VIRTIO_NET_F_STANDBY feature is negotiated. This is for automatic hot-plugging and datapath switching (in host kernel).&lt;br /&gt;
&lt;br /&gt;
2. Another way is to involve the management layer. Oracle has posted patches for QEMU: https://patchwork.kernel.org/cover/10721503/&lt;br /&gt;
This patch set introduces two new events, 1. is emitted when the VIRTIO_NET_F_STANDBY features is negotiated, 2. is emitted when the virtio_net driver is removed (manually or during a reboot). It also remove vfio devices from guest during reboot which are markes with x-failover-primary flag. &lt;br /&gt;
&lt;br /&gt;
=== How does netvsc do failover and migration ===&lt;br /&gt;
The netvsc driver doesn&#039;t use the net_failover module. In fact it was&lt;br /&gt;
written before net_failover existed. It does have very similar features&lt;br /&gt;
though, built-in to the netvsc driver itself. It creates a&lt;br /&gt;
logical devices, the netvsc device. It manages VF&lt;br /&gt;
devices as they are hot-plugged. As a new device is detected it is&lt;br /&gt;
grabbed and made a slave of the netvsc device. The VF device is usually &lt;br /&gt;
renamed by udev and gets a persistant name. It is also marked with the &lt;br /&gt;
SLAVE flag so that networking tools that are smart enough can recognize &lt;br /&gt;
the connection between netvsc and VF device. &lt;br /&gt;
During creation/initialization of the netvsc device the slower VMBUS&lt;br /&gt;
channel is set up as data-path.&lt;br /&gt;
When a VF based device is&lt;br /&gt;
registered it is matched with a corresponding netvsc device. At this point  &lt;br /&gt;
the netvsc driver enslaves the VF device and&lt;br /&gt;
the datapath is now switched over it.           &lt;br /&gt;
The failover data-path is a VMBUS channel. It is switched to when the VF&lt;br /&gt;
device is unplugged or becomes malfunctioning.   &lt;br /&gt;
&lt;br /&gt;
For the user the bond between the two devices is transparent. The netvsc&lt;br /&gt;
device is created and becomes the interface over which 1. all traffic is&lt;br /&gt;
routed and 2. all configuration is done to. When a VF device is hotplugged&lt;br /&gt;
the data-path will be automatically fast and on &lt;br /&gt;
failure/initializtion/shutdown/migration the driver switches to the slower &lt;br /&gt;
VMBUS channel.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;br /&gt;
# Other ways of marking two devices as standby/primary. Assigning identical MAC addresses could be problematic/confusing, e.g. what if more than two devices with identical MAC addresses show up. Which one to choose? Ideas for other ways to recognize devices that belong together:&lt;br /&gt;
## Assign an ID to both devices. Where to store the ID? PCI config space? -&amp;gt; no way to know what part of config space is unused.&lt;br /&gt;
## Put devices behind a PCI(e) bridge with a special device ID. The two devices on this bridge are supposed to form a failover/standby/primary device set.&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173987</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173987"/>
		<updated>2019-01-16T13:08:17Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* Problems/Questions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst or in https://www.kernel.org/doc/html/latest/networking/net_failover.html&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device still has a lot of open questions.&lt;br /&gt;
&lt;br /&gt;
What is currently explored are two ways of orchestrating datapath switching in case of (for example) a migration.&lt;br /&gt;
&lt;br /&gt;
1. A way that tries to encapsulate the mechanism in qemu/host and avoids involving the management layer.  mark the virtio device in qemu as hidden if specified on qemu cmdline. save the virtio-net device cmdline params for later. virtio device is &#039;unhidden&#039; when VIRTIO_NET_F_STANDBY feature is negotiated. This is for automatic hot-plugging and datapath switching (in host kernel).&lt;br /&gt;
&lt;br /&gt;
2. Another way is to involve the management layer. Oracle has posted patches for QEMU: https://patchwork.kernel.org/cover/10721503/&lt;br /&gt;
This patch set introduces two new events, 1. is emitted when the VIRTIO_NET_F_STANDBY features is negotiated, 2. is emitted when the virtio_net driver is removed (manually or during a reboot). It also remove vfio devices from guest during reboot which are markes with x-failover-primary flag. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;br /&gt;
# Other ways of marking two devices as standby/primary. Assigning identical MAC addresses could be problematic/confusing, e.g. what if more than two devices with identical MAC addresses show up. Which one to choose? Ideas for other ways to recognize devices that belong together:&lt;br /&gt;
## Assign an ID to both devices. Where to store the ID? PCI config space? -&amp;gt; no way to know what part of config space is unused.&lt;br /&gt;
## Put devices behind a PCI(e) bridge with a special device ID. The two devices on this bridge are supposed to form a failover/standby/primary device set.&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173986</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173986"/>
		<updated>2019-01-16T13:02:40Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* Failover for networking devices */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst or in https://www.kernel.org/doc/html/latest/networking/net_failover.html&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device still has a lot of open questions.&lt;br /&gt;
&lt;br /&gt;
What is currently explored are two ways of orchestrating datapath switching in case of (for example) a migration.&lt;br /&gt;
&lt;br /&gt;
1. A way that tries to encapsulate the mechanism in qemu/host and avoids involving the management layer.  mark the virtio device in qemu as hidden if specified on qemu cmdline. save the virtio-net device cmdline params for later. virtio device is &#039;unhidden&#039; when VIRTIO_NET_F_STANDBY feature is negotiated. This is for automatic hot-plugging and datapath switching (in host kernel).&lt;br /&gt;
&lt;br /&gt;
2. Another way is to involve the management layer. Oracle has posted patches for QEMU: https://patchwork.kernel.org/cover/10721503/&lt;br /&gt;
This patch set introduces two new events, 1. is emitted when the VIRTIO_NET_F_STANDBY features is negotiated, 2. is emitted when the virtio_net driver is removed (manually or during a reboot). It also remove vfio devices from guest during reboot which are markes with x-failover-primary flag. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173985</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173985"/>
		<updated>2019-01-16T12:18:18Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* Failover for networking devices */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst or in https://www.kernel.org/doc/html/latest/networking/net_failover.html&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device is still an open problem especially with&lt;br /&gt;
respect to minimize the downtime/loss of packets in case of a migration. &lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173984</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173984"/>
		<updated>2019-01-16T12:17:32Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* Problems/Questions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device is still an open problem especially with&lt;br /&gt;
respect to minimize the downtime/loss of packets in case of a migration. &lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;br /&gt;
## PCI Overview - Qemu: https://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173983</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173983"/>
		<updated>2019-01-16T12:14:05Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* Problems/Questions = */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device is still an open problem especially with&lt;br /&gt;
respect to minimize the downtime/loss of packets in case of a migration. &lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ===&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready. Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Failover&amp;diff=173982</id>
		<title>Failover</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Failover&amp;diff=173982"/>
		<updated>2019-01-16T12:12:42Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: Created page with &amp;quot; == Failover for networking devices ==  Current status (as of January 2019):  The guest driver model is described in linux kernel Documentation/networking/net_failover.rst  Th...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Failover for networking devices ==&lt;br /&gt;
&lt;br /&gt;
Current status (as of January 2019): &lt;br /&gt;
The guest driver model is described in linux kernel Documentation/networking/net_failover.rst&lt;br /&gt;
&lt;br /&gt;
The hypervisor part, especially how to unplug, re-plug the SR-IOV device is still an open problem especially with&lt;br /&gt;
respect to minimize the downtime/loss of packets in case of a migration. &lt;br /&gt;
&lt;br /&gt;
=== Problems/Questions ====&lt;br /&gt;
# Packet loss due to early mac filter update&lt;br /&gt;
## Some NIC drivers will update the MAC filter as soon as  a vf is created, but before the vf driver is loaded in the guest and the vf device is ready.&amp;lt;br&amp;gt;&lt;br /&gt;
Therefore packets are not going to the standby(virtio) device but to the pf until the guest is up and the vf driver is loaded.&lt;br /&gt;
## Todos: create a tool to test if a NIC driver acts like this. Idea: test without a VM involved. In host test where packets go when a mac address is added to a vf on a vlan and same mac address is added to pf. pf should not be in promiscuous mode(?).  Packets can be generated and send with tool &#039;mausezahn&#039; of netsniff-ng and it can be determined where packets end up by using &#039;netsniff-ng&#039; on pf and vf device. Status: set up tools and environment to test (2019-01-16)&lt;br /&gt;
## What to do with the results of this test? 1. Can we add a flag to the device to mark it as not usable for failover? Where to put the flag&lt;br /&gt;
# How to support hotplug of a primary/SR-IOV device for failover. Guest is already up, SR-IOV device is hotplugged in hypervisor. Device shows up in guest. How can we make it primary device in a failover/standby/primary trio?&lt;br /&gt;
# How to involve management layer in migration process? Patches sent from Oracle with rationale to make it work with old nics as well. Idea is to sent events for busmaster enable/disable.&lt;br /&gt;
## Can it be made race free? Probably yes, but we&#039;d need to stop vcpu.&lt;br /&gt;
## Can we use switchdev to program FDBs on NIC and redirect traffic from pf to vf. Can we avoid need to stop vcpu with this? Which commands to use to program FDB entries offloaded to NIC (bridge?)&lt;br /&gt;
# Mechanisms to pci device removal&lt;br /&gt;
## pci surprise removal (as defined in pci(e) spec). might be buggy in some linux drivers, but fixes are welcome, surprise removal expected to work in general. What about EMI (electric mechanical interlock) support in Linux/Qemu?&lt;br /&gt;
## ordered removal/with guest cooperation. hw has &#039;attention&#039; button. send interrupt to guest, guest ejects device. what needs to be done for that? probably only with q35 chip set. QEMU press attention button: &#039;pcie_abp 0&#039;&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Packed_virtqueue_performance&amp;diff=173981</id>
		<title>Packed virtqueue performance</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Packed_virtqueue_performance&amp;diff=173981"/>
		<updated>2019-01-08T15:18:15Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Packed virtqueue performance results ==&lt;br /&gt;
&lt;br /&gt;
This page is to share results of packed virtqueue implementations.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;DPDK:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Jens:&lt;br /&gt;
PVP setup as described in DPDK PVP reference document.&lt;br /&gt;
&lt;br /&gt;
CPU: Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz&lt;br /&gt;
NICs: 2 XL710 NICs connected back-to-back. T-Rex as traffic generator. &lt;br /&gt;
RHEL7.6, DPDK commit 1fd95c1&lt;br /&gt;
&lt;br /&gt;
./binary-search.py         --traffic-generator=trex-txrx         --search-runtime=20         --validation-runtime=20         --rate-unit=mpps --rate=20         --run-bidirec=1         --run-revunidirec=0         --frame-size=64 --num-flows=1         --one-shot=0        --max-loss-pct=0.05&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Packed virtqueues:&#039;&#039;&#039;&lt;br /&gt;
RESULT:&lt;br /&gt;
[&lt;br /&gt;
{&lt;br /&gt;
    &amp;quot;rx_bandwidth&amp;quot;: 10442536860.843485,&lt;br /&gt;
    &amp;quot;rx_packets&amp;quot;: 311247037,&lt;br /&gt;
    &amp;quot;rx_pps&amp;quot;: 15539489.376255184,&lt;br /&gt;
    &amp;quot;tx_bandwidth&amp;quot;: 10442619999.325993,&lt;br /&gt;
    &amp;quot;tx_packets&amp;quot;: 311249515,&lt;br /&gt;
    &amp;quot;tx_pps&amp;quot;: 15539613.094235107,&lt;br /&gt;
    &amp;quot;tx_pps_target&amp;quot;: 15576171.875&lt;br /&gt;
}&lt;br /&gt;
,&lt;br /&gt;
{&lt;br /&gt;
    &amp;quot;rx_bandwidth&amp;quot;: 10442079599.189692,&lt;br /&gt;
    &amp;quot;rx_packets&amp;quot;: 311233408,&lt;br /&gt;
    &amp;quot;rx_pps&amp;quot;: 15538808.927365614,&lt;br /&gt;
    &amp;quot;tx_bandwidth&amp;quot;: 10442619999.325993,&lt;br /&gt;
    &amp;quot;tx_packets&amp;quot;: 311249515,&lt;br /&gt;
    &amp;quot;tx_pps&amp;quot;: 15539613.094235107,&lt;br /&gt;
    &amp;quot;tx_pps_target&amp;quot;: 15576171.875&lt;br /&gt;
}&lt;br /&gt;
]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Split virtqueues:&#039;&#039;&#039;&lt;br /&gt;
RESULT:&lt;br /&gt;
[&lt;br /&gt;
{&lt;br /&gt;
    &amp;quot;rx_bandwidth&amp;quot;: 10444998619.78674,&lt;br /&gt;
    &amp;quot;rx_packets&amp;quot;: 311141603,&lt;br /&gt;
    &amp;quot;rx_pps&amp;quot;: 15543152.708015982,&lt;br /&gt;
    &amp;quot;tx_bandwidth&amp;quot;: 10448621216.958544,&lt;br /&gt;
    &amp;quot;tx_packets&amp;quot;: 311249515,&lt;br /&gt;
    &amp;quot;tx_pps&amp;quot;: 15548543.47761688,&lt;br /&gt;
    &amp;quot;tx_pps_target&amp;quot;: 15576171.875&lt;br /&gt;
}&lt;br /&gt;
,&lt;br /&gt;
{&lt;br /&gt;
    &amp;quot;rx_bandwidth&amp;quot;: 10448611448.11192,&lt;br /&gt;
    &amp;quot;rx_packets&amp;quot;: 311249224,&lt;br /&gt;
    &amp;quot;rx_pps&amp;quot;: 15548528.940642737,&lt;br /&gt;
    &amp;quot;tx_bandwidth&amp;quot;: 10448621216.958544,&lt;br /&gt;
    &amp;quot;tx_packets&amp;quot;: 311249515,&lt;br /&gt;
    &amp;quot;tx_pps&amp;quot;: 15548543.47761688,&lt;br /&gt;
    &amp;quot;tx_pps_target&amp;quot;: 15576171.875&lt;br /&gt;
}&lt;br /&gt;
]&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Packed_virtqueue_performance&amp;diff=173980</id>
		<title>Packed virtqueue performance</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Packed_virtqueue_performance&amp;diff=173980"/>
		<updated>2019-01-08T15:02:52Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Packed virtqueue performance results ==&lt;br /&gt;
&lt;br /&gt;
This page is to share results of packed virtqueue implementations.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;DPDK:&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Jens:&lt;br /&gt;
PVP setup as described in DPDK PVP reference document.&lt;br /&gt;
&lt;br /&gt;
CPU: Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz&lt;br /&gt;
NICs: 2 XL710 NICs connected back-to-back. T-Rex as traffic generator. &lt;br /&gt;
RHEL7.6&lt;br /&gt;
&lt;br /&gt;
./binary-search.py         --traffic-generator=trex-txrx         --search-runtime=20         --validation-runtime=20         --rate-unit=mpps --rate=20         --run-bidirec=1         --run-revunidirec=0         --frame-size=64 --num-flows=1         --one-shot=0        --max-loss-pct=0.05&lt;br /&gt;
&lt;br /&gt;
RESULT:&lt;br /&gt;
[&lt;br /&gt;
{&lt;br /&gt;
    &amp;quot;rx_bandwidth&amp;quot;: 10442536860.843485,&lt;br /&gt;
    &amp;quot;rx_packets&amp;quot;: 311247037,&lt;br /&gt;
    &amp;quot;rx_pps&amp;quot;: 15539489.376255184,&lt;br /&gt;
    &amp;quot;tx_bandwidth&amp;quot;: 10442619999.325993,&lt;br /&gt;
    &amp;quot;tx_packets&amp;quot;: 311249515,&lt;br /&gt;
    &amp;quot;tx_pps&amp;quot;: 15539613.094235107,&lt;br /&gt;
    &amp;quot;tx_pps_target&amp;quot;: 15576171.875&lt;br /&gt;
}&lt;br /&gt;
,&lt;br /&gt;
{&lt;br /&gt;
    &amp;quot;rx_bandwidth&amp;quot;: 10442079599.189692,&lt;br /&gt;
    &amp;quot;rx_packets&amp;quot;: 311233408,&lt;br /&gt;
    &amp;quot;rx_pps&amp;quot;: 15538808.927365614,&lt;br /&gt;
    &amp;quot;tx_bandwidth&amp;quot;: 10442619999.325993,&lt;br /&gt;
    &amp;quot;tx_packets&amp;quot;: 311249515,&lt;br /&gt;
    &amp;quot;tx_pps&amp;quot;: 15539613.094235107,&lt;br /&gt;
    &amp;quot;tx_pps_target&amp;quot;: 15576171.875&lt;br /&gt;
}&lt;br /&gt;
]&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=Packed_virtqueue_performance&amp;diff=173979</id>
		<title>Packed virtqueue performance</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=Packed_virtqueue_performance&amp;diff=173979"/>
		<updated>2019-01-08T13:02:13Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: Created page with &amp;quot; == Packed virtqueue performance results ==  This page is to share results of packed virtqueue implementations.  &amp;#039;&amp;#039;&amp;#039;DPDK:&amp;#039;&amp;#039;&amp;#039;&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Packed virtqueue performance results ==&lt;br /&gt;
&lt;br /&gt;
This page is to share results of packed virtqueue implementations.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;DPDK:&#039;&#039;&#039;&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=User_talk:Jensfr&amp;diff=173978</id>
		<title>User talk:Jensfr</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=User_talk:Jensfr&amp;diff=173978"/>
		<updated>2019-01-08T12:55:00Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: /* Packed virtqueue performance results */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=User_talk:Jensfr&amp;diff=173977</id>
		<title>User talk:Jensfr</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=User_talk:Jensfr&amp;diff=173977"/>
		<updated>2019-01-08T12:54:27Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Packed virtqueue performance results ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This page is to share performance results of packed virtqueue implementations. Please also share test setup, configuration etc.&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=User_talk:Jensfr&amp;diff=173976</id>
		<title>User talk:Jensfr</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=User_talk:Jensfr&amp;diff=173976"/>
		<updated>2019-01-08T12:49:59Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: Packed virtqueue performance results&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page is to share performance results of packed virtqueue implementations. Please also share test setup, configuration etc.&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=KVM_Forum_2017&amp;diff=173888</id>
		<title>KVM Forum 2017</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=KVM_Forum_2017&amp;diff=173888"/>
		<updated>2018-01-08T20:52:43Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;includeonly&amp;gt;&lt;br /&gt;
== [http://www.linux-kvm.org/page/KVM_Forum_2017 KVM Forum 2017] ==&lt;br /&gt;
&amp;lt;/includeonly&amp;gt;&lt;br /&gt;
&amp;lt;noinclude&amp;gt;&lt;br /&gt;
== KVM Forum 2017 ==&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The 10th edition of the [https://events.linuxfoundation.org/events/kvm-forum KVM Forum] was held from 25 - 27 October at the Hilton Prague in Prague, Czech Republic. &lt;br /&gt;
&lt;br /&gt;
== Live Updates ==&lt;br /&gt;
&lt;br /&gt;
Watch the [https://plus.google.com/107691536544094955898/posts Google+ Group] for live updates from the event.&lt;br /&gt;
&lt;br /&gt;
== Videos and Slides ==&lt;br /&gt;
&lt;br /&gt;
==== Wednesday - October 25, 2017 ====&lt;br /&gt;
===== Wednesday Morning =====&lt;br /&gt;
* Lessons in Running libvirtd at Scale - Prerna Saxena, Nutanix ([https://www.youtube.com/watch?v=acf38ee5WzI video] [https://www.linux-kvm.org/images/c/c2/Libvirt-ppt_kvmf.pdf slides])&lt;br /&gt;
* OMG, NPIV! Virtualizing Fibre Channel with Linux and KVM - Paolo Bonzini, Red Hat, Inc. &amp;amp; Hannes Reinecke, SUSE ([https://www.youtube.com/watch?v=ME1IdbtaU5E video] [https://www.linux-kvm.org/images/d/dd/Kvmforum17-npiv.pdf slides])&lt;br /&gt;
&lt;br /&gt;
===== Wednesday Afternoon =====&lt;br /&gt;
* QEMU in UEFI - Alexander Graf, SUSE ([https://www.youtube.com/watch?v=uxvAH1Q4Mx0 video] [https://www.linux-kvm.org/images/b/b4/QEMU_in_UEFI.pdf slides])&lt;br /&gt;
* The Future of virtio: Riddles, Myths and Surprises - Michael S. Tsirkin/Jens Freimann, Red Hat, Inc. ([https://www.youtube.com/watch?v=z9cWwgYH97A&amp;amp;t=3s video] [https://www.linux-kvm.org/images/0/03/Virtio_fall_2017.pdf slides])&lt;br /&gt;
* Helping Users Maximize VM Performance - Martin Polednik, Red Hat, Inc. ([https://www.youtube.com/watch?v=_SlUlQRcnQg video] [https://www.linux-kvm.org/images/3/37/Kvm_forum17_max_vm_perf.pdf slides])&lt;br /&gt;
* KVM Performance Tuning on Alibaba Cloud - Yang Zhang, Alibaba Cloud ([https://www.youtube.com/watch?v=i3kNI7hTF8g video] [https://www.linux-kvm.org/images/c/cf/KVM_performance_tuning_on_Alibaba_Cloud.pdf slides])&lt;br /&gt;
&lt;br /&gt;
==== Thursday - October 26, 2017 ====&lt;br /&gt;
===== Thursday Morning =====&lt;br /&gt;
* Keynote: KVM Status Report - Christian Bornträger, IBM ([https://www.youtube.com/watch?v=S9FpBvoj1zA video] [slides])&lt;br /&gt;
* To EL2, and Beyond! - Christoffer Dall, Linaro ([https://www.youtube.com/watch?v=j0bp4fnO98w video] [https://www.linux-kvm.org/images/a/a1/To_EL2_and_Beyond_0.pdf slides])&lt;br /&gt;
* Running Virtual Machines on Kubernetes with libvirt &amp;amp; KVM - Fabian Deutsch &amp;amp; Roman Mohr, Red Hat, Inc. ([https://www.youtube.com/watch?v=Wh-ejUyuHJ0 video]                                                                           [http://slides.com/fabiand/running-virtual-machines-on-kubernetes-with-kvm-and-libvirt-alt2#/ slides])&lt;br /&gt;
* Managing the New Block Layer - Kevin Wolf &amp;amp; Max Reitz, Red Hat, Inc.([https://www.youtube.com/watch?v=9-CA7M8C7wI video] [https://www.linux-kvm.org/images/5/5b/Block_Layer_Talk_11.pdf slides])&lt;br /&gt;
* Bringing Commercial Grade Virtual Machine Introspection to KVM - Mihai Donțu, Bitdefender ([https://www.youtube.com/watch?v=sUPSogabV-o video] [https://www.linux-kvm.org/images/7/72/KVMForum2017_Introspection.pdf slides])&lt;br /&gt;
* Qemu Backup - Vladimir Sementsov-Ogievskiy &amp;amp; Maxim Nestratov, Virtuozzo ([https://www.youtube.com/watch?v=Mp0ATSdxtUY videos] [https://www.linux-kvm.org/images/e/e6/Kvm-forum2017_backup.pdf slides])&lt;br /&gt;
* Nested Virtualization on ARM - Christoffer Dall, Linaro ([https://www.youtube.com/watch?v=cuXyGkZRUKU videos] [https://www.linux-kvm.org/images/f/fc/Nested_ARM_Virt_0.pdf slides])&lt;br /&gt;
&lt;br /&gt;
===== Thursday Afternoon =====&lt;br /&gt;
* Live Migration with Mediated Device - Yulei Zhang, Intel ([https://www.youtube.com/watch?v=ZAzv0c-fdAc videos] [https://www.linux-kvm.org/images/f/fa/Live_migration_with_mdev_device_-_2017_0.pdf slides])&lt;br /&gt;
* Zero-Copy Receive for vhost - Mike Rapoport, IBM ([https://www.youtube.com/watch?v=szA5h7od634 videos] [https://www.linux-kvm.org/images/1/1e/Zero-copy_receive_for_vhost.pdf slides])&lt;br /&gt;
* Generic Buffer Sharing Mechanism for Mediated Devices - Tina Zhang, Intel ([https://www.youtube.com/watch?v=cHMLBcHplhk videos] [https://www.linux-kvm.org/images/c/c6/Generic_Buffer_Sharing_Mechanism_for_Mediated_Devices.pdf slides])&lt;br /&gt;
* Configuring and Benchmarking Open vSwitch, DPDK and vhost-user - Pei Zhang, Red Hat, Inc. ([https://www.youtube.com/watch?v=OnTQRgUyiv8 videos] [https://www.linux-kvm.org/images/c/c8/DPDK.pdf slides])&lt;br /&gt;
* Adding Device Direct Assignment Support for a New Bus Infrastructure on ARM64: Challenges and Performance Tuning - Mihai Caraman, NXP ([https://www.youtube.com/watch?v=kMKjF2RBKYE videos] [slides])&lt;br /&gt;
* virtio: vhost Data Path Acceleration towards NFV Cloud - Cunming Liang, Intel ([https://www.youtube.com/watch?v=v50-rXGMr-Y videos] [https://www.linux-kvm.org/images/8/87/KVM17vDPA-v4_0.pdf slides]) &lt;br /&gt;
* Userspace NVMe driver in QEMU - Fam Zheng, Red Hat, Inc. ([https://www.youtube.com/watch?v=bwyHxb4tng0 videos] [https://www.linux-kvm.org/images/4/4c/Userspace_NVMe_driver_in_QEMU_-_Fam_Zheng.pdf slides])&lt;br /&gt;
* Improve VNF Safety with Vhost-User/DPDK IOMMU Support - Maxime Coquelin, Red Hat, Inc. ([https://www.youtube.com/watch?v=amlhowbtlSw videos] [slides])&lt;br /&gt;
* Where Does the Time Go? Profiling Nested KVM on x86/Intel - Jim Mattson, Google ([https://www.youtube.com/watch?v=PxDHNfrpwHE videos] [https://www.linux-kvm.org/images/3/32/KVM_Forum_2017_-_Profiling_Nested_KVM.pdf slides])&lt;br /&gt;
* virtio-crypto: A New Framework of Cryptography Virtio Device - Lei Gong, Huawei &amp;amp; Xin Zeng, Intel ([https://www.youtube.com/watch?v=9SYHRYcNa_w videos] [slides])&lt;br /&gt;
* Nested Virtualization: Hyper-V on KVM - Ladi Prosek, Red Hat, Inc. ([https://www.youtube.com/watch?v=zQSkKgpj9jA videos] [https://www.linux-kvm.org/images/6/6a/HyperV-KVM.pdf slides])&lt;br /&gt;
* Testing Techniques Applied to Virt Development - Cleber Rosa, Red Hat, Inc. ([https://www.youtube.com/watch?v=4cRceasctUI videos] [https://www.linux-kvm.org/images/1/19/Kvm_forum_2017_avocado.pdf slides])&lt;br /&gt;
&lt;br /&gt;
==== Friday - October 27, 2017 ====&lt;br /&gt;
===== Friday Morning =====&lt;br /&gt;
* Keynote: QEMU Status Report - Paolo Bonzini, Red Hat, Inc. ([https://www.youtube.com/watch?v=PZ7H_5s8yqE video] [slides])&lt;br /&gt;
* Failing Migrations: How &amp;amp; Why - Dr. David Alan Gilbert, Red Hat, Inc. ([https://www.youtube.com/watch?v=Ku8zgSeGjrM video] [slides])&lt;br /&gt;
* Multi-Process QEMU - Marc-Andre Lureau, Red Hat, Inc. &amp;amp; Konrad Rzeszutek Wilk, Oracle [https://www.youtube.com/watch?v=Kq1-coHh7lg video] [https://www.linux-kvm.org/images/f/fc/KVM_FORUM_multi-process.pdf slides])&lt;br /&gt;
* vIOMMU/ARM: Full Emulation and virtio-iommu Approaches - Eric Auger, Red Hat, Inc. ([https://www.youtube.com/watch?v=7aZAsanbKwI video] [https://www.linux-kvm.org/images/8/8e/Viommu_arm.pdf slides])&lt;br /&gt;
* Introducing vhost-user-scsi and It&#039;s Applications - Felipe Franciosi, Nutanix &amp;amp; James Harris, Intel ([https://www.youtube.com/watch?v=DxqEaCPijlI video] [https://www.linux-kvm.org/images/6/61/KVM_Forum_vhost-user-scsi.pdf slides])&lt;br /&gt;
* Measuring the Effects of Turbo on VMs - Benjamin Serebrin, Google ([https://www.youtube.com/watch?v=kcQfHTGPg2g video] [https://www.linux-kvm.org/images/2/2d/KVM_Forum_2017_-_Serebrin_-_Measuring_the_Effects_of_Turbo_on_VMs.pdf slides])&lt;br /&gt;
* RDMA is Coming to QEMU - Yuval Shaia, Oracle &amp;amp; Marcel Apfelbaum, Red Hat, Inc. ([https://www.youtube.com/watch?v=z3JAS6qluCk video] [slides])&lt;br /&gt;
&lt;br /&gt;
===== Friday Afternoon =====&lt;br /&gt;
* Fast Write-Protect and Fast Dirtylog-Bitmap Sync Up - Guangrong Xiao, Tencent Cloud ([https://www.youtube.com/watch?v=kJt348q8OZQ video] [https://www.linux-kvm.org/images/e/eb/Guangrong-fast-write-protection.pdf slides])&lt;br /&gt;
* Towards a More Expressive and Introspectable QEMU Command Line - Markus Armbruster, Red Hat, Inc. ([https://www.youtube.com/watch?v=gtpOLQgnwug video] [https://www.linux-kvm.org/images/f/f2/Armbru-qapi-cmdline_1.pdf slides])&lt;br /&gt;
* Live Migration at Ali-Cloud: Issues Settled &amp;amp; Challenges Remain - Chao Zhang, Alibaba Cloud ([https://www.youtube.com/watch?v=-IcHsnQ1S30 video] [https://www.linux-kvm.org/images/e/e3/Live_Migration_Alibaba_Cloud.pdf slides])&lt;br /&gt;
* libtcg: Exposing QEMU&#039;s TCG Frontend to External Tools - Alessandro Di Federico, Politecnico di Milano ([https://www.youtube.com/watch?v=zCu1pyfSaCY video] [slides])&lt;br /&gt;
* Keynote: Libvirt Status Report - Peter Krempa ([https://www.youtube.com/watch?v=kXMZefakcAI video] [https://www.linux-kvm.org/images/b/b6/Libvirt-status-report-2017.pdf slides])&lt;br /&gt;
* Applying Polling Techniques to QEMU: Reducing virtio-blk I/O Latency - Stefan Hajnoczi, Red Hat, Inc. ([https://www.youtube.com/watch?v=g2Wlia9bo88 video] [https://www.linux-kvm.org/images/0/0a/Stefanha-kvm-forum-2017.pdf slides])&lt;br /&gt;
* Instrumenting, Introspection, and Debugging with QEMU - Pavel Dovgalyuk, ISPRAS ([https://www.youtube.com/watch?v=3g1KzfBl1kI video] [https://www.linux-kvm.org/images/3/3d/Introspect.pdf slides])&lt;br /&gt;
* Improving the Performance of the qcow2 Format - Alberto Garcia, Igalia ([https://www.youtube.com/watch?v=kmUxIOTiGNo video] [https://www.linux-kvm.org/images/e/e2/Qcow2_perf.pdf slides])&lt;br /&gt;
* Linux-User Support in QEMU - Riku Voipio, Linaro ([https://www.youtube.com/watch?v=4MaGnMGPIq0 video] [slides])&lt;br /&gt;
* How to Handle Globally Distributed qcow2 Chains - Eyal Moscovici &amp;amp; Amit Abir, Oracle Ravello Systems ([https://www.youtube.com/watch?v=EMK7KVDHSNg video] [https://www.linux-kvm.org/images/7/7b/How_to_Handle_Globally_Distributed_QCOW2_Chains_final_01.pdf slides])&lt;br /&gt;
* Vectoring in on QEMU&#039;s TCG Engine - Alex Bennée, Linaro ([https://www.youtube.com/watch?v=IYHTwnde0g8 video] [https://www.linux-kvm.org/images/3/32/Vectoring_in_on_QEMU_TCG_Engine.pdf slides])&lt;br /&gt;
&lt;br /&gt;
== Schedule ==&lt;br /&gt;
https://kvmforum2017.sched.com/&lt;br /&gt;
&lt;br /&gt;
== BoFs ==&lt;br /&gt;
&lt;br /&gt;
[[KVM Forum 2017 BOF]]&lt;br /&gt;
&lt;br /&gt;
== Community Team Photo ==&lt;br /&gt;
&lt;br /&gt;
== Photos ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Blogs / News Reports ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__NOTOC__&lt;br /&gt;
&lt;br /&gt;
[[Category:KVMForum]][[Category:Conferences]]&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=File:Virtio_fall_2017.pdf&amp;diff=173887</id>
		<title>File:Virtio fall 2017.pdf</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=File:Virtio_fall_2017.pdf&amp;diff=173887"/>
		<updated>2018-01-08T20:47:37Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: The Future of virtio: Riddles, Myths and Surprises, KVM Forum 2017 talk&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Future of virtio: Riddles, Myths and Surprises, KVM Forum 2017 talk&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=KVM_Forum_2017&amp;diff=173886</id>
		<title>KVM Forum 2017</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=KVM_Forum_2017&amp;diff=173886"/>
		<updated>2018-01-08T20:44:40Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;includeonly&amp;gt;&lt;br /&gt;
== [http://www.linux-kvm.org/page/KVM_Forum_2017 KVM Forum 2017] ==&lt;br /&gt;
&amp;lt;/includeonly&amp;gt;&lt;br /&gt;
&amp;lt;noinclude&amp;gt;&lt;br /&gt;
== KVM Forum 2017 ==&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The 10th edition of the [https://events.linuxfoundation.org/events/kvm-forum KVM Forum] was held from 25 - 27 October at the Hilton Prague in Prague, Czech Republic. &lt;br /&gt;
&lt;br /&gt;
== Live Updates ==&lt;br /&gt;
&lt;br /&gt;
Watch the [https://plus.google.com/107691536544094955898/posts Google+ Group] for live updates from the event.&lt;br /&gt;
&lt;br /&gt;
== Videos and Slides ==&lt;br /&gt;
&lt;br /&gt;
==== Wednesday - October 25, 2017 ====&lt;br /&gt;
===== Wednesday Morning =====&lt;br /&gt;
* Lessons in Running libvirtd at Scale - Prerna Saxena, Nutanix ([https://www.youtube.com/watch?v=acf38ee5WzI video] [https://www.linux-kvm.org/images/c/c2/Libvirt-ppt_kvmf.pdf slides])&lt;br /&gt;
* OMG, NPIV! Virtualizing Fibre Channel with Linux and KVM - Paolo Bonzini, Red Hat, Inc. &amp;amp; Hannes Reinecke, SUSE ([https://www.youtube.com/watch?v=ME1IdbtaU5E video] [https://www.linux-kvm.org/images/d/dd/Kvmforum17-npiv.pdf slides])&lt;br /&gt;
&lt;br /&gt;
===== Wednesday Afternoon =====&lt;br /&gt;
* QEMU in UEFI - Alexander Graf, SUSE ([https://www.youtube.com/watch?v=uxvAH1Q4Mx0 video] [https://www.linux-kvm.org/images/b/b4/QEMU_in_UEFI.pdf slides])&lt;br /&gt;
* The Future of virtio: Riddles, Myths and Surprises - Michael S. Tsirkin/Jens Freimann, Red Hat, Inc. ([https://www.youtube.com/watch?v=z9cWwgYH97A&amp;amp;t=3s video] [slides])&lt;br /&gt;
* Helping Users Maximize VM Performance - Martin Polednik, Red Hat, Inc. ([https://www.youtube.com/watch?v=_SlUlQRcnQg video] [https://www.linux-kvm.org/images/3/37/Kvm_forum17_max_vm_perf.pdf slides])&lt;br /&gt;
* KVM Performance Tuning on Alibaba Cloud - Yang Zhang, Alibaba Cloud ([https://www.youtube.com/watch?v=i3kNI7hTF8g video] [https://www.linux-kvm.org/images/c/cf/KVM_performance_tuning_on_Alibaba_Cloud.pdf slides])&lt;br /&gt;
&lt;br /&gt;
==== Thursday - October 26, 2017 ====&lt;br /&gt;
===== Thursday Morning =====&lt;br /&gt;
* Keynote: KVM Status Report - Christian Bornträger, IBM ([https://www.youtube.com/watch?v=S9FpBvoj1zA video] [slides])&lt;br /&gt;
* To EL2, and Beyond! - Christoffer Dall, Linaro ([https://www.youtube.com/watch?v=j0bp4fnO98w video] [https://www.linux-kvm.org/images/a/a1/To_EL2_and_Beyond_0.pdf slides])&lt;br /&gt;
* Running Virtual Machines on Kubernetes with libvirt &amp;amp; KVM - Fabian Deutsch &amp;amp; Roman Mohr, Red Hat, Inc. ([https://www.youtube.com/watch?v=Wh-ejUyuHJ0 video]                                                                           [http://slides.com/fabiand/running-virtual-machines-on-kubernetes-with-kvm-and-libvirt-alt2#/ slides])&lt;br /&gt;
* Managing the New Block Layer - Kevin Wolf &amp;amp; Max Reitz, Red Hat, Inc.([https://www.youtube.com/watch?v=9-CA7M8C7wI video] [https://www.linux-kvm.org/images/5/5b/Block_Layer_Talk_11.pdf slides])&lt;br /&gt;
* Bringing Commercial Grade Virtual Machine Introspection to KVM - Mihai Donțu, Bitdefender ([https://www.youtube.com/watch?v=sUPSogabV-o video] [https://www.linux-kvm.org/images/7/72/KVMForum2017_Introspection.pdf slides])&lt;br /&gt;
* Qemu Backup - Vladimir Sementsov-Ogievskiy &amp;amp; Maxim Nestratov, Virtuozzo ([https://www.youtube.com/watch?v=Mp0ATSdxtUY videos] [https://www.linux-kvm.org/images/e/e6/Kvm-forum2017_backup.pdf slides])&lt;br /&gt;
* Nested Virtualization on ARM - Christoffer Dall, Linaro ([https://www.youtube.com/watch?v=cuXyGkZRUKU videos] [https://www.linux-kvm.org/images/f/fc/Nested_ARM_Virt_0.pdf slides])&lt;br /&gt;
&lt;br /&gt;
===== Thursday Afternoon =====&lt;br /&gt;
* Live Migration with Mediated Device - Yulei Zhang, Intel ([https://www.youtube.com/watch?v=ZAzv0c-fdAc videos] [https://www.linux-kvm.org/images/f/fa/Live_migration_with_mdev_device_-_2017_0.pdf slides])&lt;br /&gt;
* Zero-Copy Receive for vhost - Mike Rapoport, IBM ([https://www.youtube.com/watch?v=szA5h7od634 videos] [https://www.linux-kvm.org/images/1/1e/Zero-copy_receive_for_vhost.pdf slides])&lt;br /&gt;
* Generic Buffer Sharing Mechanism for Mediated Devices - Tina Zhang, Intel ([https://www.youtube.com/watch?v=cHMLBcHplhk videos] [https://www.linux-kvm.org/images/c/c6/Generic_Buffer_Sharing_Mechanism_for_Mediated_Devices.pdf slides])&lt;br /&gt;
* Configuring and Benchmarking Open vSwitch, DPDK and vhost-user - Pei Zhang, Red Hat, Inc. ([https://www.youtube.com/watch?v=OnTQRgUyiv8 videos] [https://www.linux-kvm.org/images/c/c8/DPDK.pdf slides])&lt;br /&gt;
* Adding Device Direct Assignment Support for a New Bus Infrastructure on ARM64: Challenges and Performance Tuning - Mihai Caraman, NXP ([https://www.youtube.com/watch?v=kMKjF2RBKYE videos] [slides])&lt;br /&gt;
* virtio: vhost Data Path Acceleration towards NFV Cloud - Cunming Liang, Intel ([https://www.youtube.com/watch?v=v50-rXGMr-Y videos] [https://www.linux-kvm.org/images/8/87/KVM17vDPA-v4_0.pdf slides]) &lt;br /&gt;
* Userspace NVMe driver in QEMU - Fam Zheng, Red Hat, Inc. ([https://www.youtube.com/watch?v=bwyHxb4tng0 videos] [https://www.linux-kvm.org/images/4/4c/Userspace_NVMe_driver_in_QEMU_-_Fam_Zheng.pdf slides])&lt;br /&gt;
* Improve VNF Safety with Vhost-User/DPDK IOMMU Support - Maxime Coquelin, Red Hat, Inc. ([https://www.youtube.com/watch?v=amlhowbtlSw videos] [slides])&lt;br /&gt;
* Where Does the Time Go? Profiling Nested KVM on x86/Intel - Jim Mattson, Google ([https://www.youtube.com/watch?v=PxDHNfrpwHE videos] [https://www.linux-kvm.org/images/3/32/KVM_Forum_2017_-_Profiling_Nested_KVM.pdf slides])&lt;br /&gt;
* virtio-crypto: A New Framework of Cryptography Virtio Device - Lei Gong, Huawei &amp;amp; Xin Zeng, Intel ([https://www.youtube.com/watch?v=9SYHRYcNa_w videos] [slides])&lt;br /&gt;
* Nested Virtualization: Hyper-V on KVM - Ladi Prosek, Red Hat, Inc. ([https://www.youtube.com/watch?v=zQSkKgpj9jA videos] [https://www.linux-kvm.org/images/6/6a/HyperV-KVM.pdf slides])&lt;br /&gt;
* Testing Techniques Applied to Virt Development - Cleber Rosa, Red Hat, Inc. ([https://www.youtube.com/watch?v=4cRceasctUI videos] [https://www.linux-kvm.org/images/1/19/Kvm_forum_2017_avocado.pdf slides])&lt;br /&gt;
&lt;br /&gt;
==== Friday - October 27, 2017 ====&lt;br /&gt;
===== Friday Morning =====&lt;br /&gt;
* Keynote: QEMU Status Report - Paolo Bonzini, Red Hat, Inc. ([https://www.youtube.com/watch?v=PZ7H_5s8yqE video] [slides])&lt;br /&gt;
* Failing Migrations: How &amp;amp; Why - Dr. David Alan Gilbert, Red Hat, Inc. ([https://www.youtube.com/watch?v=Ku8zgSeGjrM video] [slides])&lt;br /&gt;
* Multi-Process QEMU - Marc-Andre Lureau, Red Hat, Inc. &amp;amp; Konrad Rzeszutek Wilk, Oracle [https://www.youtube.com/watch?v=Kq1-coHh7lg video] [https://www.linux-kvm.org/images/f/fc/KVM_FORUM_multi-process.pdf slides])&lt;br /&gt;
* vIOMMU/ARM: Full Emulation and virtio-iommu Approaches - Eric Auger, Red Hat, Inc. ([https://www.youtube.com/watch?v=7aZAsanbKwI video] [https://www.linux-kvm.org/images/8/8e/Viommu_arm.pdf slides])&lt;br /&gt;
* Introducing vhost-user-scsi and It&#039;s Applications - Felipe Franciosi, Nutanix &amp;amp; James Harris, Intel ([https://www.youtube.com/watch?v=DxqEaCPijlI video] [https://www.linux-kvm.org/images/6/61/KVM_Forum_vhost-user-scsi.pdf slides])&lt;br /&gt;
* Measuring the Effects of Turbo on VMs - Benjamin Serebrin, Google ([https://www.youtube.com/watch?v=kcQfHTGPg2g video] [https://www.linux-kvm.org/images/2/2d/KVM_Forum_2017_-_Serebrin_-_Measuring_the_Effects_of_Turbo_on_VMs.pdf slides])&lt;br /&gt;
* RDMA is Coming to QEMU - Yuval Shaia, Oracle &amp;amp; Marcel Apfelbaum, Red Hat, Inc. ([https://www.youtube.com/watch?v=z3JAS6qluCk video] [slides])&lt;br /&gt;
&lt;br /&gt;
===== Friday Afternoon =====&lt;br /&gt;
* Fast Write-Protect and Fast Dirtylog-Bitmap Sync Up - Guangrong Xiao, Tencent Cloud ([https://www.youtube.com/watch?v=kJt348q8OZQ video] [https://www.linux-kvm.org/images/e/eb/Guangrong-fast-write-protection.pdf slides])&lt;br /&gt;
* Towards a More Expressive and Introspectable QEMU Command Line - Markus Armbruster, Red Hat, Inc. ([https://www.youtube.com/watch?v=gtpOLQgnwug video] [https://www.linux-kvm.org/images/f/f2/Armbru-qapi-cmdline_1.pdf slides])&lt;br /&gt;
* Live Migration at Ali-Cloud: Issues Settled &amp;amp; Challenges Remain - Chao Zhang, Alibaba Cloud ([https://www.youtube.com/watch?v=-IcHsnQ1S30 video] [https://www.linux-kvm.org/images/e/e3/Live_Migration_Alibaba_Cloud.pdf slides])&lt;br /&gt;
* libtcg: Exposing QEMU&#039;s TCG Frontend to External Tools - Alessandro Di Federico, Politecnico di Milano ([https://www.youtube.com/watch?v=zCu1pyfSaCY video] [slides])&lt;br /&gt;
* Keynote: Libvirt Status Report - Peter Krempa ([https://www.youtube.com/watch?v=kXMZefakcAI video] [https://www.linux-kvm.org/images/b/b6/Libvirt-status-report-2017.pdf slides])&lt;br /&gt;
* Applying Polling Techniques to QEMU: Reducing virtio-blk I/O Latency - Stefan Hajnoczi, Red Hat, Inc. ([https://www.youtube.com/watch?v=g2Wlia9bo88 video] [https://www.linux-kvm.org/images/0/0a/Stefanha-kvm-forum-2017.pdf slides])&lt;br /&gt;
* Instrumenting, Introspection, and Debugging with QEMU - Pavel Dovgalyuk, ISPRAS ([https://www.youtube.com/watch?v=3g1KzfBl1kI video] [https://www.linux-kvm.org/images/3/3d/Introspect.pdf slides])&lt;br /&gt;
* Improving the Performance of the qcow2 Format - Alberto Garcia, Igalia ([https://www.youtube.com/watch?v=kmUxIOTiGNo video] [https://www.linux-kvm.org/images/e/e2/Qcow2_perf.pdf slides])&lt;br /&gt;
* Linux-User Support in QEMU - Riku Voipio, Linaro ([https://www.youtube.com/watch?v=4MaGnMGPIq0 video] [slides])&lt;br /&gt;
* How to Handle Globally Distributed qcow2 Chains - Eyal Moscovici &amp;amp; Amit Abir, Oracle Ravello Systems ([https://www.youtube.com/watch?v=EMK7KVDHSNg video] [https://www.linux-kvm.org/images/7/7b/How_to_Handle_Globally_Distributed_QCOW2_Chains_final_01.pdf slides])&lt;br /&gt;
* Vectoring in on QEMU&#039;s TCG Engine - Alex Bennée, Linaro ([https://www.youtube.com/watch?v=IYHTwnde0g8 video] [https://www.linux-kvm.org/images/3/32/Vectoring_in_on_QEMU_TCG_Engine.pdf slides])&lt;br /&gt;
&lt;br /&gt;
== Schedule ==&lt;br /&gt;
https://kvmforum2017.sched.com/&lt;br /&gt;
&lt;br /&gt;
== BoFs ==&lt;br /&gt;
&lt;br /&gt;
[[KVM Forum 2017 BOF]]&lt;br /&gt;
&lt;br /&gt;
== Community Team Photo ==&lt;br /&gt;
&lt;br /&gt;
== Photos ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Blogs / News Reports ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
__NOTOC__&lt;br /&gt;
&lt;br /&gt;
[[Category:KVMForum]][[Category:Conferences]]&lt;br /&gt;
&amp;lt;/noinclude&amp;gt;&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
	<entry>
		<id>https://linux-kvm.org/index.php?title=KVM_Forum_2017_BOF&amp;diff=173845</id>
		<title>KVM Forum 2017 BOF</title>
		<link rel="alternate" type="text/html" href="https://linux-kvm.org/index.php?title=KVM_Forum_2017_BOF&amp;diff=173845"/>
		<updated>2017-10-19T07:57:55Z</updated>

		<summary type="html">&lt;p&gt;Jensfr: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Introduction =&lt;br /&gt;
&lt;br /&gt;
We will reserve some time for people to get together and discuss&lt;br /&gt;
strategic decisions as well as other topics that are best solved within&lt;br /&gt;
smaller groups. This time can also be used for hands-on hacking&lt;br /&gt;
sessions.&lt;br /&gt;
&lt;br /&gt;
If you are interested in organizing such a group time event, please add&lt;br /&gt;
it to the list &#039;&#039;&#039;before&#039;&#039;&#039; KVM Forum, so people have time to organize which&lt;br /&gt;
one they will attend.&lt;br /&gt;
&lt;br /&gt;
Adding links to this wiki is restricted. If you have problems adding your&lt;br /&gt;
BoF, please send it to the program committee at&lt;br /&gt;
[mailto:kvm-forum-2017-pc@redhat.com kvm-forum-2017-pc@redhat.com].&lt;br /&gt;
&lt;br /&gt;
= BoF Ideas =&lt;br /&gt;
&lt;br /&gt;
=== Windows guests on KVM/QEMU ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Anything and everything related to running Windows on KVM/QEMU&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
What&#039;s new, what&#039;s broken, what&#039;s coming in the future. Topics may include (feel free to add your own):&lt;br /&gt;
&lt;br /&gt;
* Windows guest performance tuning&lt;br /&gt;
* VMbus on KVM&lt;br /&gt;
* Hyper-V nested on KVM&lt;br /&gt;
* Windows drivers for new virtio devices (virtio-gpu, virtio-vsock, virtio-9p, ...)&lt;br /&gt;
* Hyper-V enlightenments exposed by KVM&lt;br /&gt;
* Debugging, host-side MEMORY.DMP generation&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Links:&#039;&#039;&#039;&lt;br /&gt;
* [https://github.com/virtio-win/kvm-guest-drivers-windows virtio-win GitHub page]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;People:&#039;&#039;&#039;&lt;br /&gt;
* Ladi Prosek &amp;lt;lprosek@redhat.com&amp;gt; (organizer)&lt;br /&gt;
* Denis Lunev &amp;lt;den@openvz.org&amp;gt;&lt;br /&gt;
* Roman Kagan &amp;lt;rkagan@virtuozzo.com&amp;gt;&lt;br /&gt;
* Yan Vugenfirer &amp;lt;yan@daynix.com&amp;gt;&lt;br /&gt;
* Dmitry Fleytman &amp;lt;dmitry@daynix.com&amp;gt;&lt;br /&gt;
* Sameeh Jubran &amp;lt;sameeh@daynix.com&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Better ballooning ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Summary:&#039;&#039;&#039; &lt;br /&gt;
Let&#039;s figure out what virtio-balloon (or its successor) should look like.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Topics:&#039;&#039;&#039; &#039;&#039;(feel free to add more!)&#039;&#039;&lt;br /&gt;
* Inflation semantics: Should a host be able to target free pages specifically?&lt;br /&gt;
* Deflation semantics: Should a guest be able to touch ballooned pages?&lt;br /&gt;
* OOM handling: How can one avoid OOM-related guest impact (OOM-kills, swapping, etc.)?&lt;br /&gt;
* Protocol (incl. efficient advertisement of pages)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Links:&#039;&#039;&#039; &#039;&#039;(feel free to add more!)&#039;&#039;&lt;br /&gt;
* [https://www.spinics.net/lists/kvm/msg156658.html &amp;lt;nowiki&amp;gt;[Patch v3 0/5]&amp;lt;/nowiki&amp;gt; KVM: Guest page hinting]&lt;br /&gt;
* [https://www.spinics.net/lists/kvm/msg151523.html &amp;lt;nowiki&amp;gt;[RFC] virtio-mem: paravirtualized memory&amp;lt;/nowiki&amp;gt;]&lt;br /&gt;
* [https://www.spinics.net/lists/kvm/msg152734.html &amp;lt;nowiki&amp;gt;[PATCH v12 0/8] Virtio-balloon Enhancement&amp;lt;/nowiki&amp;gt;]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;People:&#039;&#039;&#039;&lt;br /&gt;
* Randy Dodgen &amp;lt;dodgen@google.com&amp;gt; (organizer)&lt;br /&gt;
&lt;br /&gt;
=== Virtio 1.1 ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Summary:&#039;&#039;&#039; Discussion of current Virtio 1.1 draft proposal&lt;br /&gt;
&lt;br /&gt;
Discussion about Virtio 1.1 has been going on for a while on mailing lists. One driver for&lt;br /&gt;
a new version of the Virtio spec has been interest in a hardware implementation of virtio.&lt;br /&gt;
Let&#039;s discuss this further and see if there&#039;s any further feedback and ideas.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Links:&#039;&#039;&#039;&lt;br /&gt;
* [https://lists.oasis-open.org/archives/virtio-dev/201702/msg00010.html packed ring layout proposal v2]&lt;br /&gt;
* [https://lists.oasis-open.org/archives/virtio-dev/201709/msg00013.html packed ring layout proposal v3]&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;People:&#039;&#039;&#039;&lt;br /&gt;
* Jens Freimann (organizer)&lt;br /&gt;
* Michael Tsirkin&lt;br /&gt;
* Maxime Coquelin&lt;br /&gt;
* Amnon Ilan&lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
== BoF idea template ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
=== TITLE ===&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Summary:&#039;&#039;&#039; Short description of the idea&lt;br /&gt;
&lt;br /&gt;
Detailed description of the idea.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Links:&#039;&#039;&#039;&lt;br /&gt;
* Wiki links to relevant material&lt;br /&gt;
* External links to mailing lists or web sites&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;People:&#039;&#039;&#039;&lt;br /&gt;
* Your Name (organizer)&lt;br /&gt;
* People that want to attend this session&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;/div&gt;</summary>
		<author><name>Jensfr</name></author>
	</entry>
</feed>