From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhang, Xiantao" Subject: Re: [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at boot Date: Tue, 20 May 2014 00:46:46 +0000 Message-ID: References: <535E254A020000780000CA9A@nat28.tlf.novell.com> <535E26DE020000780000CAC8@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WmYCh-0007MN-Ip for xen-devel@lists.xenproject.org; Tue, 20 May 2014 00:46:51 +0000 In-Reply-To: <535E26DE020000780000CAC8@nat28.tlf.novell.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , xen-devel Cc: "Dugger, Donald D" List-Id: xen-devel@lists.xenproject.org Thanks, Acked-by: Xiantao Zhang Xiantao. > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Monday, April 28, 2014 4:01 PM > To: xen-devel > Cc: Dugger, Donald D; Zhang, Xiantao > Subject: [PATCH 1/2] VT-d: apply quirks at device setup time rather than only at > boot > > Accessing extended config space may not be possible at boot time, e.g. > when the memory space used by MMCFG is reserved only via ACPI tables, but > not in the E820/UEFI memory maps (which we need Dom0 to tell us about). > Consequently the change here still leaves the issue unaddressed for systems > where the extended config space remains inaccessible (due to firmware bugs, > i.e. not properly reserving the address space of those regions). > > With the respective messages now potentially getting logged more than once, > we ought to consider whether we should issue them only if we in fact were > required to do any masking (i.e. if the relevant mask bits weren't already set). > > This is CVE-2013-3495 / XSA-59. > > Signed-off-by: Jan Beulich > > --- a/xen/drivers/passthrough/vtd/extern.h > +++ b/xen/drivers/passthrough/vtd/extern.h > @@ -99,7 +99,7 @@ void platform_quirks_init(void); void > vtd_ops_preamble_quirk(struct iommu* iommu); void > vtd_ops_postamble_quirk(struct iommu* iommu); void me_wifi_quirk(struct > domain *domain, u8 bus, u8 devfn, int map); -void pci_vtd_quirk(struct pci_dev > *pdev); > +void pci_vtd_quirk(const struct pci_dev *); > int platform_supports_intremap(void); > int platform_supports_x2apic(void); > > --- a/xen/drivers/passthrough/vtd/iommu.c > +++ b/xen/drivers/passthrough/vtd/iommu.c > @@ -1483,6 +1483,9 @@ static int domain_context_mapping( > break; > } > > + if ( !ret && devfn == pdev->devfn ) > + pci_vtd_quirk(pdev); > + > return ret; > } > > @@ -1922,6 +1925,8 @@ static int intel_iommu_enable_device(str > struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev); > int ret = drhd ? ats_device(pdev, drhd) : -ENODEV; > > + pci_vtd_quirk(pdev); > + > if ( ret <= 0 ) > return ret; > > @@ -1994,12 +1999,7 @@ static int intel_iommu_remove_device(u8 > > static int __hwdom_init setup_hwdom_device(u8 devfn, struct pci_dev *pdev) > { > - int err; > - > - err = domain_context_mapping(pdev->domain, devfn, pdev); > - if ( !err && devfn == pdev->devfn ) > - pci_vtd_quirk(pdev); > - return err; > + return domain_context_mapping(pdev->domain, devfn, pdev); > } > > void clear_fault_bits(struct iommu *iommu) > --- a/xen/drivers/passthrough/vtd/quirks.c > +++ b/xen/drivers/passthrough/vtd/quirks.c > @@ -385,7 +385,7 @@ void me_wifi_quirk(struct domain *domain > * - This can cause system failure upon non-fatal VT-d faults > * - Potential security issue if malicious guest trigger VT-d faults > */ > -void __hwdom_init pci_vtd_quirk(struct pci_dev *pdev) > +void pci_vtd_quirk(const struct pci_dev *pdev) > { > int seg = pdev->seg; > int bus = pdev->bus; > >