PCI-DM-HELPER

Pci-dm-helper is a helper started through the xenvm toolstack to receive request from a stub-domain to access a passed-through PCI device config. space. It will also give the stubdomain the required IO permissions depending on the device.

This project is deprecated in 5.0.0 and later version of OpenXT.

Dependencies

libpciaccess

v4v (libv4v)

xenctrl (libxc)

xenstore (libxenstore)

IOEMU support (patch stubdoms, https://github.com/OpenXT-Extras/ioemu-pq/blob/master/master/stubdoms)

Use and Context

Toolstack relationship

The toolstack is responsible for starting this helper when required. As this helper is listening on the v4v-socker through which RPC will be sent by the device model, it must be ready before the stub-domain, as re-connection is not mandatory in the device-model. Currently started in dm.ml.

Usage

pci-dm-helper guest-domid stub-domain-id
	guest-domid	domid of the guest
	stub-domain-id	domid of the stub-domain handling the device-model for guest-domid

Features

pci-dm-helper will give appropriate permissions to the stub-domain to access relevant resources for the device passed-through and handle request to access its config. space.

Access permission

Permissions are attributed to the stub-domain by reading pci-backend/frontend Xenstore entries:

• /local/domain/0/backend/pci/<stubdom-id>/0/num_devs
• /local/domain/0/backend/pci/<stubdom-id>/0/dev-<devid> pci-dm-helper

will retrieve each device BDF and assign permissions depending on the device: - Not a graphic card (pci-device-class != 0x300), no permission - Any graphic card, 0x3b0-0x3cf ports and 0xa0000-0xbffff io-memory access - Intel Graphic Device (pci-vendor-id == 0x8086), 0x3c0-0x3df ports; if the device exposes an op-region (address at pci config. space 0xfc), stub-domain will be given permission to access as well, - ATI graphic card (pci-vendor-id == 0x1002), 0x3c0-0x3c2 and 0x3c4-0x3df ports.

Remote PCI config. space access

pci-dm-helper will open a listening socket over v4v on port 5559 and wait for incomming connection. Once connection is established, the remote client will be able to send packet structures to request read/write to the config. space of a device. Such packets are formated as:

struct remotepci_req {
    unsigned read:1;
    unsigned write:1;
    unsigned align:6;
    u_int16_t domain;
    u_int8_t bus, dev, func;
    u_int16_t offset;
    union {
        u_int32_t len;
        u_int32_t v;
    };
} __attribute__((packed));

PCI pass-through: VGAbios copy

Guest's might expect the VGAbios from a pass-through card to be mapped at 0xc0000 (e.g Intel Graphic Card). This is not handled by hvmloader; it will only load the default built-in VGABios. Pci-dm-helper will copy the VGAbios from dom0 at 0xc0000 to the guest 0xc0000 (using xc_map_foreign_range()).

IGD Passthrough

This section is incomplete. It is mainly a dump of what can be remembered about the kinds of things that had to be done to make IGD passthrough work.

• The guest drivers had to have access to the VGA IO ports at 0x3C0 (see http://wiki.osdev.org/VGA_Hardware#Port_0x3C0).  Pci-dm-helper make it available to guests using xc_domain_ioport_permission.
• The guest drivers had to have access to the IGD Opregion MMIO region. The base address is fetched from the IGD device's config space. Pci-dm-helper used to fetch the location and make it available to guests using xc_domain_iomem_permission.
• The actual VGABios of the IGD card had to be loaded into the guest at the legacy OROM slot 0xC0000. As noted above, pci-dm-helper did this.
• The guest drivers got a filtered list of IGD device capabilities. This was done in IOEMU (IIRC?). The functionality was probably dropped in the QEMU 1.4 uprev.
• The guest drivers needed access to the IGD device and platform's vendor capabilities stored as a vendor specific capability on the host bridge device (00:0.0). This was done in IOEMU pass-through code.  The functionality dropped in the QEMU 1.4 uprev.
• The guest drivers expected to see a legacy ISA bridge surfaced at 00:1f.0 on the PCI bus. A dummy device was surfaced by IOEMU. The functionality dropped in the QEMU 1.4 uprev.
• The QEMU support patch 0007-pci-reserve-igd-slot.patch is gone.

Several versions of IGD passthrough were posted for inclusion in Xen/QEMU. If IGD passthrough were brought back, it should be based on this work.

Better yet, with a proper graphics stack, GVT-g and XenGT would be the way to go.