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

["Kay, Allen M" <allen.m.kay@xxxxxxxxx>]

Yes.  Ack!

Allen

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxx] 
Sent: Friday, October 07, 2011 12:18 AM
To: Kay, Allen M
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: 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