[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> -----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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.