veyepar: VFIO - Virtual Fabric IO a.k.a. PCI pass-through

Author(s):	Alexey Kardashevskiy
Location	OGGB4
Date	jan Thu 15	Days Raw Files
Start	10:40	First Raw Start	10:37
Duration	0:45:00	Offset	0:02:53
End	11:25	Last Raw End	11:40
Chapters	00:00
Total cuts_time	29 min.

http://lca2015.linux.org.au/schedule/30231/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf VFIO_Virtual_Fabric_IO_aka_PCI_passthrough.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

VFIO is a virtual fabric IO mechanism which intends to provide the
userspace access to real devices such as PCI hardware. There are 2 uses of
this:
1) a usual userspace program which knows specific PCI hardware and can use
for custom application (high speed trading?);
2) pass it to a guest OS - so called "PCI Passthrough" - and this is what
the talk is all about.

There were 2 challenges in implementing VFIO:

1. Protect guest/host memory from other guest or host.
PCI passthrough requires virtualization support from the host hardware, the
feature is called "IOMMU". Different architectures support different IOMMU
models, the existing guest systems also have different capabilities
regarding IOMMU support/requirements. Current VFIO supports x86 and POWERPC
(server and embedded).

2. Provide implementation with minimum overhead compared to the bare metal
performance when uses with KVM. This includes DMA and MMIO acceleration.
Different approaches are used for x86 and POWERPC.

3. Support tweaks/quirks which various devices might want such as
power-on-self-test and so on. Support various types of device reset is the
most annoying part of this.

Comment:

production notes