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

Re: [Xen-devel] [PATCH v3 08/10] vpci: register as an internal ioreq server



On 30.09.2019 15:32, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -29,6 +29,7 @@
>  
>  #include <asm/bzimage.h>
>  #include <asm/dom0_build.h>
> +#include <asm/hvm/ioreq.h>
>  #include <asm/hvm/support.h>
>  #include <asm/io_apic.h>
>  #include <asm/p2m.h>

This is the only change to this file, and there's no addition to
asm/hvm/ioreq.h - how come this #include is needed?

> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -20,6 +20,8 @@
>  #include <xen/sched.h>
>  #include <xen/vpci.h>
>  
> +#include <asm/hvm/ioreq.h>

This of course means a step away from the code here being generic
enough such that Arm could eventually use it. Independent of this
aspect perhaps the #include would better move ...

> @@ -478,6 +480,61 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg, 
> unsigned int size,
>      spin_unlock(&pdev->vpci->lock);
>  }
>  
> +#ifdef __XEN__

... here?

> +static int ioreq_handler(ioreq_t *req, void *data)
> +{
> +    pci_sbdf_t sbdf;
> +
> +    /*
> +     * NB: certain requests of type different than PCI are broadcasted to all
> +     * registered ioreq servers, ignored those.
> +     */
> +    if ( req->type != IOREQ_TYPE_PCI_CONFIG || req->data_is_ptr )
> +        return X86EMUL_UNHANDLEABLE;

I understand the left side of the || , but why the right side? There
shouldn't be any IOREQ_TYPE_PCI_CONFIG requests with data_is_ptr set,
should there? I also didn't think requests with data_is_ptr set would
get broadcast?

> +int vpci_register_ioreq(struct domain *d)
> +{
> +    ioservid_t id;
> +    int rc;
> +
> +    if ( !has_vpci(d) )
> +        return 0;
> +
> +    rc = hvm_create_ioreq_server(d, HVM_IOREQSRV_BUFIOREQ_OFF, &id, true);
> +    if ( rc )
> +        return rc;
> +
> +    rc = hvm_set_ioreq_handler(d, id, ioreq_handler, NULL);
> +    if ( rc )
> +        return rc;
> +
> +    if ( is_hardware_domain(d) )
> +    {
> +        /* Handle all devices in vpci. */
> +        rc = hvm_map_io_range_to_ioreq_server(d, id, XEN_DMOP_IO_RANGE_PCI,
> +                                              0, ~(uint64_t)0);
> +        if ( rc )
> +            return rc;
> +    }
> +
> +    rc = hvm_set_ioreq_server_state(d, id, true);
> +    if ( rc )
> +        return rc;
> +
> +    return rc;

This last sequence of statements looks a little odd - is this in
anticipation of further additions to the function?

Furthermore the only caller expects the function to clean up after
itself (i.e. partially completed setup be undone), which doesn't
look to be the case here. I can't seem to be able to convince
myself that all of this gets cleaned up.

Jan

_______________________________________________
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®.