[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci cap on host bridge.
>>> On 07.02.13 at 17:12, Rui Guo <firemeteor@xxxxxxxxxxxxxxxxxxxxx> wrote: > +static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t > config_addr, int len, > + uint32_t *val) > +{ > + struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0); > + uint32_t vendor_cap = 0; > + uint32_t cap_type = 0; > + uint32_t cap_size = 0; > + > + vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, > 1); > + if (!vendor_cap) > + return 0; > + > + cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1); > + if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE) > + return 0; > + > + if (config_addr == PCI_INTEL_VENDOR_CAP) > + { > + *val = vendor_cap; > + return 1; > + } > + > + /* Remove the next capability link */ > + if (config_addr == vendor_cap + 1) > + { > + *val = 0; > + return 1; > + } It doesn't look right to ignore "len" up to here? What if this is a word read at "vendor_cap"? Also, why would removing the next capability be correct here, when you're not removing _all_ other capabilities? > + > + cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1); > + if (config_addr >= vendor_cap && > + config_addr + len <= vendor_cap + cap_size) > + { > + *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len); > + return 1; > + } Similarly such a read wouldn't get handled consistently (with the above intention) here: You're not masking off the byte at "vendor_cap + 1". > + /* Exposing writable register does not lead to security risk since this > + only apply to read. This may confuse the guest, but it works good so > far. > + Will switch to mask & merge style only if this is proved broken. > + Note: Always expose aligned address if any byte of the dword is to be > + exposed. This provides a consistent view, at least for read. */ Such a comment is certainly not helping being confident in the changes you're trying to get merged in. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |