[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 5/9] sysctl: Add sysctl interface for querying PCI topology
>>> On 10.03.15 at 03:27, <boris.ostrovsky@xxxxxxxxxx> wrote: > + case XEN_SYSCTL_pcitopoinfo: > + { > + xen_sysctl_pcitopoinfo_t *ti = &op->u.pcitopoinfo; > + > + if ( guest_handle_is_null(ti->devs) || > + guest_handle_is_null(ti->nodes) || > + (ti->first_dev > ti->num_devs) ) > + { > + ret = -EINVAL; > + break; > + } > + > + for ( ; ti->first_dev < ti->num_devs; ti->first_dev++ ) > + { > + physdev_pci_device_t dev; > + uint8_t node; > + struct pci_dev *pdev; > + > + if ( copy_from_guest_offset(&dev, ti->devs, ti->first_dev, 1) ) > + { > + ret = -EFAULT; > + break; > + } > + > + spin_lock(&pcidevs_lock); > + pdev = pci_get_pdev(dev.seg, dev.bus, dev.devfn); > + if ( !pdev || (pdev->node == NUMA_NO_NODE) ) > + node = XEN_INVALID_NODE_ID; > + else > + node = pdev->node; > + spin_unlock(&pcidevs_lock); > + > + if ( copy_to_guest_offset(ti->nodes, ti->first_dev, &node, 1) ) > + { > + ret = -EFAULT; > + break; > + } > > + if ( hypercall_preempt_check() ) > + break; > + } > + > + if ( !ret ) > + { > + ti->first_dev++; This is correct in the preempt case, but it seems wrong to me in the completely-done one. Perhaps it would be better to put the increment right before the preempt check? > +struct xen_sysctl_pcitopoinfo { > + /* IN: Size of pcitopo array */ > + uint32_t num_devs; > + > + /* > + * IN/OUT: First element of pcitopo array that needs to be processed by > + * hypervisor. > + * This is used primarily by hypercall continuations and callers will > + * typically set it to zero. > + */ > + uint32_t first_dev; > + > + /* IN: list of devices */ > + XEN_GUEST_HANDLE_64(physdev_pci_device_t) devs; > + > + /* > + * OUT: node identifier for each device. > + * If information for a particular device is not avalable then set > + * to XEN_INVALID_NODE_ID. > + */ > + XEN_GUEST_HANDLE_64(uint8) nodes; As said in earlier patches - let's not expose the 8-bit limitation to user space, avoiding needless changes going forward. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |