search for: pci_bus_num

...> + if (class != object_class_by_name(TYPE_PCI_BUS) && > + class != object_class_by_name(TYPE_PCIE_BUS)) { > + error_setg(errp, "%s is not a device on pci bus", id); > + return -1; > + } > + busnum = (uint16_t)pci_bus_num(PCI_BUS(bus)); > + } pci_bus_num is almost always a bug if not done within a context of a PCI host, bridge, etc. In particular this will not DTRT if run before guest assigns bus numbers. > + > + if (!devfn) > + goto out; > + > + pd = strchr(pc, '.'); &g...

On 04/04/2018 10:02, Siwei Liu wrote: >> pci_bus_num is almost always a bug if not done within >> a context of a PCI host, bridge, etc. >> >> In particular this will not DTRT if run before guest assigns bus >> numbers. >> > I was seeking means to reserve a specific pci bus slot from drivers, > and update the driver...

...ass != object_class_by_name(TYPE_PCI_BUS) && >> + class != object_class_by_name(TYPE_PCIE_BUS)) { >> + error_setg(errp, "%s is not a device on pci bus", id); >> + return -1; >> + } >> + busnum = (uint16_t)pci_bus_num(PCI_BUS(bus)); >> + } > > pci_bus_num is almost always a bug if not done within > a context of a PCI host, bridge, etc. > > In particular this will not DTRT if run before guest assigns bus > numbers. > I was seeking means to reserve a specific pci bus slot from drivers...

The OpRegion shouldn''t be mapped 1:1 because the address in the host can''t be used in the guest directly. This patch traps read and write access to the opregion of the Intel GPU config space (offset 0xfc). To work correctly this patch needs a change in hvmloader. HVMloader will allocate 2 pages for the OpRegion and write this address on the config space of the Intel GPU. Qemu

...ot_iort_virtio_pci_iommu *viommu; + + viommu = (struct acpi_viot_iort_virtio_pci_iommu *)node->node_data; + + val = le32_to_cpu(viommu->devid); + + devid = kzalloc(sizeof(*devid), GFP_KERNEL); + if (!devid) + return ERR_PTR(-ENOMEM); + + devid->segment = val >> 16; + devid->bus = PCI_BUS_NUM(val); + devid->devfn = val & 0xff; + + return devid; +} + struct iort_dev_config { const char *name; int (*dev_init)(struct acpi_iort_node *node); @@ -1462,6 +1497,7 @@ struct iort_dev_config { int (*dev_set_proximity)(struct device *dev, struct acpi_iort_node *node); int (...

Userspace patches for the pci-passthrough functionality. The major updates since the last post are: - Loop to add passthrough devices in pc_init1 - Handle errors in read/write calls - Allow invocation without irq number for in-kernel irqchip Other than this, several small things were fixed according to review comments received last time.

Userspace patches for the pci-passthrough functionality. The major updates since the last post are: - Loop to add passthrough devices in pc_init1 - Handle errors in read/write calls - Allow invocation without irq number for in-kernel irqchip Other than this, several small things were fixed according to review comments received last time.

...six_vector_is_used(PCIDevice *dev, unsigned vector); + +void msix_notify(PCIDevice *dev, unsigned vector); + +void msix_reset(PCIDevice *dev); + +extern int msix_disable; + +#endif diff --git a/hw/pci.c b/hw/pci.c index 35c08e6..a35aad7 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -127,12 +127,15 @@ int pci_bus_num(PCIBus *s) void pci_device_save(PCIDevice *s, QEMUFile *f) { + int version = s->cap_present ? 3 : 2; int i; - qemu_put_be32(f, 2); /* PCI device version */ + qemu_put_be32(f, version); /* PCI device version */ qemu_put_buffer(f, s->config, 256); for (i = 0; i &lt...

...six_vector_is_used(PCIDevice *dev, unsigned vector); + +void msix_notify(PCIDevice *dev, unsigned vector); + +void msix_reset(PCIDevice *dev); + +extern int msix_disable; + +#endif diff --git a/hw/pci.c b/hw/pci.c index 35c08e6..a35aad7 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -127,12 +127,15 @@ int pci_bus_num(PCIBus *s) void pci_device_save(PCIDevice *s, QEMUFile *f) { + int version = s->cap_present ? 3 : 2; int i; - qemu_put_be32(f, 2); /* PCI device version */ + qemu_put_be32(f, version); /* PCI device version */ qemu_put_buffer(f, s->config, 256); for (i = 0; i &lt...

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.

I'm seeking feedback on multi-platform support for virtio-iommu. At the moment only devicetree (DT) is supported and we don't have a pleasant solution for other platforms. Once we figure out the topology description, x86 support is trivial. Since the IOMMU manages memory accesses from other devices, the guest kernel needs to initialize the IOMMU before endpoints start issuing DMA.