search for: dev_cfg

...ap), GFP_KERNEL); + + if (!new) + return -ENOMEM; + + mutex_lock(&viommus_lock); + list_add(&new->list, &viommu_spec->topology); + mutex_unlock(&viommus_lock); + return 0; +} + +static int viommu_parse_topology(struct pci_dev *dev, int pci_cfg, + struct viommu_cap_config *dev_cfg) +{ + u32 offset; + struct viommu_topology cap; + struct viommu_spec *viommu_spec; + int iter = 0; /* Protects against config loop */ + + offset = viommu_cread(dev, pci_cfg, dev_cfg, 2, + offsetof(struct virtio_iommu_config, + topo_offset)); + if (!offset) + return 0; + + viommu_...

...OMEM; > + > + mutex_lock(&viommus_lock); > + list_add(&new->list, &viommu_spec->topology); > + mutex_unlock(&viommus_lock); > + return 0; > +} > + > +static int viommu_parse_topology(struct pci_dev *dev, int pci_cfg, > + struct viommu_cap_config *dev_cfg) > +{ > + u32 offset; > + struct viommu_topology cap; > + struct viommu_spec *viommu_spec; > + int iter = 0; /* Protects against config loop */ > + > + offset = viommu_cread(dev, pci_cfg, dev_cfg, 2, > + offsetof(struct virtio_iommu_config, > + topo_offs...

...p.\n", > + hw->notify_base); > + break; > + case VIRTIO_PCI_CAP_ISR_CFG: > + hw->isr = get_cap_addr(hw, &cap); > + IFC_INFO(&dev->dev, "hw->isr = %p.\n", hw->isr); > + break; > + case VIRTIO_PCI_CAP_DEVICE_CFG: > + hw->dev_cfg = get_cap_addr(hw, &cap); > + IFC_INFO(&dev->dev, "hw->dev_cfg = %p.\n", hw->dev_cfg); > + break; > + } > +next: > + pos = cap.cap_next; > + } > + > + if (hw->common_cfg == NULL || hw->notify_base == NULL || > + hw->isr == NULL |...

...I_CAP_ISR_CFG: >>> +??????????? hw->isr = get_cap_addr(hw, &cap); >>> +??????????? IFC_INFO(&dev->dev, "hw->isr = %p.\n", hw->isr); >>> +??????????? break; >>> +??????? case VIRTIO_PCI_CAP_DEVICE_CFG: >>> +??????????? hw->dev_cfg = get_cap_addr(hw, &cap); >>> +??????????? IFC_INFO(&dev->dev, "hw->dev_cfg = %p.\n", hw->dev_cfg); >>> +??????????? break; >>> +??????? } >>> +next: >>> +??????? pos = cap.cap_next; >>> +??? } >>> + >>&...

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.

On 2019/10/23 ??5:24, Zhu, Lingshan wrote: >>>>> >>>>> >>>>> set_config/get_config is missing. It looks to me they are not >>>>> hard, just implementing the access to dev_cfg. It's key to make >>>>> kernel virtio driver to work. >>>>> >>>>> And in the new version of virito-mdev, features like _F_LOG_ALL >>>>> should be advertised through get_mdev_features. >>>> IMHO, currently the driver can w...

...| features_lo; + + return features; +} + int ifcvf_verify_min_features(struct ifcvf_hw *hw, u64 features) { if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)) && features) { @@ -275,7 +293,7 @@ void ifcvf_write_dev_config(struct ifcvf_hw *hw, u64 offset, vp_iowrite8(*p++, hw->dev_cfg + offset + i); } -static void ifcvf_set_features(struct ifcvf_hw *hw, u64 features) +void ifcvf_set_driver_features(struct ifcvf_hw *hw, u64 features) { struct virtio_pci_common_cfg __iomem *cfg = hw->common_cfg; @@ -286,19 +304,6 @@ static void ifcvf_set_features(struct ifcvf_hw *hw, u6...

...n" > + "common cfg: %p\n" > + "notify base: %p\n" > + "isr cfg: %p\n" > + "device cfg: %p\n" > + "multiplier: %u\n", > + hw->common_cfg, > + hw->notify_base, > + hw->isr, > + hw->dev_cfg, > + hw->notify_off_multiplier); Since kernel messages go to syslog, syslog does not handle multi-line messages very well. This should be a single line. Also, this is the kind of message that should be at the debug level; something that is useful to the driver developers but not somethin...

...+ u8 old_gen, new_gen; >>>> + >>>> + do { >>>> + old_gen = ioread8(&hw->common_cfg->config_generation); >>>> + >>>> + p = dst; >>>> + for (i = 0; i < length; i++) >>>> + *p++ = ioread8((u8 *)hw->dev_cfg + offset + i); >>>> + >>>> + new_gen = ioread8(&hw->common_cfg->config_generation); >>>> + } while (old_gen != new_gen); >>> Would it be wise to limit the number of iterations of the loop above? >> Thanks but I don't quite get it. Th...

...t;>>>> + do { >>>>>> + old_gen = ioread8(&hw->common_cfg->config_generation); >>>>>> + >>>>>> + p = dst; >>>>>> + for (i = 0; i < length; i++) >>>>>> + *p++ = ioread8((u8 *)hw->dev_cfg + offset + i); >>>>>> + >>>>>> + new_gen = ioread8(&hw->common_cfg->config_generation); >>>>>> + } while (old_gen != new_gen); >>>>> Would it be wise to limit the number of iterations of the loop above? >>>>...

...| features_lo; + + return features; +} + int ifcvf_verify_min_features(struct ifcvf_hw *hw, u64 features) { if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)) && features) { @@ -275,7 +293,7 @@ void ifcvf_write_dev_config(struct ifcvf_hw *hw, u64 offset, vp_iowrite8(*p++, hw->dev_cfg + offset + i); } -static void ifcvf_set_features(struct ifcvf_hw *hw, u64 features) +void ifcvf_set_driver_features(struct ifcvf_hw *hw, u64 features) { struct virtio_pci_common_cfg __iomem *cfg = hw->common_cfg; @@ -286,19 +304,6 @@ static void ifcvf_set_features(struct ifcvf_hw *hw, u6...

...mdev_get_device_id, >>> +??? .get_vendor_id??? = ifcvf_mdev_get_vendor_id, >>> +??? .get_vq_align??? = ifcvf_mdev_get_vq_align, >>> +}; >> >> >> set_config/get_config is missing. It looks to me they are not hard, >> just implementing the access to dev_cfg. It's key to make kernel >> virtio driver to work. >> >> And in the new version of virito-mdev, features like _F_LOG_ALL >> should be advertised through get_mdev_features. > IMHO, currently the driver can work without set/get_config, vhost_mdev > doesn't cal...

....get_version = ifcvf_mdev_get_version, > + .get_device_id = ifcvf_mdev_get_device_id, > + .get_vendor_id = ifcvf_mdev_get_vendor_id, > + .get_vq_align = ifcvf_mdev_get_vq_align, > +}; set_config/get_config is missing. It looks to me they are not hard, just implementing the access to dev_cfg. It's key to make kernel virtio driver to work. And in the new version of virito-mdev, features like _F_LOG_ALL should be advertised through get_mdev_features. > + > +static int ifcvf_init_msix(struct ifcvf_adapter *adapter) > +{ > + int vector, i, ret, irq; > + struct pci_d...

Formerly, ifcvf driver has implemented a lazy-initialization mechanism for the virtqueues and other config space contents, it would store all configurations that passed down from the userspace, then load them to the device config space upon DRIVER_OK. This can not serve live migration, so this series implement an immediate initialization mechanism, which means rather than the former store-load

Formerly, ifcvf driver has implemented a lazy-initialization mechanism for the virtqueues and other config space contents, it would store all configurations that passed down from the userspace, then load them to the device config space upon DRIVER_OK. This can not serve live migration, so this series implement an immediate initialization mechanism, which means rather than the former store-load