WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: [PATCH] VT-d: don't reject possibly valid DRHD or RMRR

>>> On 07.10.11 at 03:51, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:
> For RMRR case, looks like you miss the following change (or something 
> similar):
> 
> -for ( i = 0; i < rmrru->scope.devices_cnt; i++ )
> +for (; i < rmrru->scope.devices_cnt; i++ )

Indeed.

> Otherwise, the logic for handling non-zero PCI segments looks reasonable.

So do I take this as an acked-by-with-above-change?

> Allen
> 
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] 
> Sent: Tuesday, October 04, 2011 4:30 AM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx 
> Cc: Kay, Allen M
> Subject: [PATCH] VT-d: don't reject possibly valid DRHD or RMRR
> 
> If a non-zero PCI segment isn't accessible during Xen boot (because
> firmware decided to not enter the necessary MMIO space into the E820
> table), devices referred to on those segments through DRHD or RMRR
> structures should not be rejected just because the devices can't be
> found.
> 
> This is in line with what is being done in at least one other case
> already: Systems with more than one PCI segment (usually high end
> ones) are assumed to have valid firmware provided data, while systems
> with just segment 0 continue to have their firmware tables validated.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -53,6 +53,11 @@ static inline struct pci_seg *get_pseg(u
>      return radix_tree_lookup(&pci_segments, seg);
>  }
>  
> +bool_t pci_known_segment(u16 seg)
> +{
> +    return get_pseg(seg) != NULL;
> +}
> +
>  static struct pci_seg *alloc_pseg(u16 seg)
>  {
>      struct pci_seg *pseg = get_pseg(seg);
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -444,10 +444,14 @@ acpi_parse_one_drhd(struct acpi_dmar_ent
>      else
>      {
>          u8 b, d, f;
> -        int i, invalid_cnt = 0;
> +        unsigned int i = 0, invalid_cnt = 0;
>          void *p;
>  
> -        for ( i = 0, p = dev_scope_start; i < dmaru->scope.devices_cnt;
> +        /* Skip checking if segment is not accessible yet. */
> +        if ( !pci_known_segment(drhd->segment) )
> +            i = UINT_MAX;
> +
> +        for ( p = dev_scope_start; i < dmaru->scope.devices_cnt;
>                i++, p += ((struct acpi_dev_scope *)p)->length )
>          {
>              if ( ((struct acpi_dev_scope *)p)->dev_type == ACPI_DEV_IOAPIC ||
> @@ -549,7 +553,12 @@ acpi_parse_one_rmrr(struct acpi_dmar_ent
>      else
>      {
>          u8 b, d, f;
> -        int i, ignore = 0;
> +        bool_t ignore = 0;
> +        unsigned int i = 0;
> +
> +        /* Skip checking if segment is not accessible yet. */
> +        if ( !pci_known_segment(rmrr->segment) )
> +            i = UINT_MAX;
>  
>          for ( i = 0; i < rmrru->scope.devices_cnt; i++ )
>          {
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -82,6 +82,7 @@ enum {
>      DEV_TYPE_PCI,
>  };
>  
> +bool_t pci_known_segment(u16 seg);
>  int pci_device_detect(u16 seg, u8 bus, u8 dev, u8 func);
>  int scan_pci_devices(void);
>  int pdev_type(u16 seg, u8 bus, u8 devfn);




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel