Re: [Xen-devel] [PATCH v2 08/11] ioreq: allow decoding accesses to MMCFG regions

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> Sent: 03 September 2019 17:14
> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; 
> Andrew Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; Paul Durrant 
> <Paul.Durrant@xxxxxxxxxx>
> Subject: [PATCH v2 08/11] ioreq: allow decoding accesses to MMCFG regions
> 
> Pick up on the infrastructure already added for vPCI and allow ioreq
> to decode accesses to MMCFG regions registered for a domain. This
> infrastructure is still only accessible from internal callers, so
> MMCFG regions can only be registered from the internal domain builder
> used by PVH dom0.
> 
> Note that the vPCI infrastructure to decode and handle accesses to
> MMCFG regions will be removed in following patches when vPCI is
> switched to become an internal ioreq server.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

[snip]
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 6339e5f884..fecdc2786f 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -1090,21 +1090,34 @@ int hvm_map_io_range_to_ioreq_server(struct domain 
> *d, ioservid_t id,
>          /* PCI config space accesses are handled internally. */
>          if ( start <= 0xcf8 + 8 && 0xcf8 <= end )
>              goto out;
> -        else
> -            /* fallthrough. */
> +        break;
> +
>      case XEN_DMOP_IO_RANGE_MEMORY:
> +    {
> +        const struct hvm_mmcfg *mmcfg;
> +
> +        rc = -EINVAL;
> +        /* PCI config space accesses are handled internally. */
> +        read_lock(&d->arch.hvm.mmcfg_lock);
> +        list_for_each_entry ( mmcfg, &d->arch.hvm.mmcfg_regions, next )
> +            if ( start <= mmcfg->addr + mmcfg->size && mmcfg->addr <= end )
> +            {
> +                read_unlock(&d->arch.hvm.mmcfg_lock);
> +                goto out;
> +            }
> +        read_unlock(&d->arch.hvm.mmcfg_lock);
> +        break;
> +    }
> +

Like with cf8 registration, I don't think you want to error here. It's never 
been a hard error for an external emulator to attempt to register for accesses 
that are actually handled within Xen. Doing so would mean that we may need to 
teach QEMU what Xen does and doesn't deal with internally and that seems like 
an unnecessary headache.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel