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

Re: [Xen-devel] [PATCH v4 19/33] xen/arm: Implement hypercall DOMCTL_{, un}bind_pt_pirq



On Thu, 2015-03-19 at 19:29 +0000, Julien Grall wrote:
> On x86, an IRQ is assigned in 2 steps to an HVM guest:
>     - The toolstack is calling PHYSDEVOP_map_pirq in order to create a
>     guest PIRQ (IRQ bound to an event channel)
>     - The emulator (QEMU) is calling DOMCTL_bind_pt_irq in order to
>     bind the IRQ
> 
> On ARM, there is no concept of PIRQ as the IRQ can be assigned to a
> virtual IRQ using the interrupt controller.
> 
> It's not clear if we will need 2 different hypercalls on ARM to assign
> IRQ and, for now, only the toolstack will manage IRQ.
> 
> In order to avoid re-using a fixed ABI hypercall (PHYSDEVOP_*) for a
> different purpose and allow us more time to figure out the right out,

"figure out the right way"

> only DOMCTL_{,un}bind_pt_pirq is implemented on ARM.
> 
> The DOMCTL is extended with a new type PT_IRQ_TYPE_SPI and only IRQ ==
> vIRQ (i.e machine_irq == spi) is supported.
> 
> Concerning XSM, even if ARM is using one hypercall rather than 2, the
> resulting check is nearly the same.
> 
> XSM PHYSDEVOP_map_pirq:
>     1) Check if the current domain can add resource to the domain
>     2) Check if the current domain has permission to add the IRQ
>     3) Check if the target domain has permission to use the IRQ
> 
> XSM DOMCTL_bind_pirq_irq:
>     1) Check if the current domain can add resource to the domain
>     2) Check if the current domain has permission to bind the IRQ
>     3) Check if the target domain has permission to use the IRQ
> 
> Rather than checking that the current domain can both add and bind the
> IRQ, we only check the bind permission. I think this is not a big deal
> because we don't have emulator on ARM and therefore no disaggregation is
> required.

Is this because we don't have the "add" concept on arm?

> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 579d266..8243b70 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -1764,7 +1764,7 @@ int xc_domain_bind_pt_irq(
>      uint8_t bus,
>      uint8_t device,
>      uint8_t intx,
> -    uint8_t isa_irq)
> +    uint16_t isa_irq)

This interface is pretty awful, taking the union of all the options
needed for each type as separate parameters. Reusing the isa_irq
parameter is making this worse along a different axis as well.

AFAICT its only user is qemu-trad with PT_IRQ_TYPE_MSI_TRANSLATE.

I think we should discourage any new uses of this function, and hide any
ugliness in an internal static function to be used by the more specific
xc_domain_bind_pt_isa_irq et al. i.e. make the current
xc_doamin_bind_pt_irq an internal helper with a new name and a new
spi_irq parameter and make the replacement xc_domain_bind_pt_irq a
wrapper which handles only the set of types which it handles today and a
new xc_domain_bind_pt_spi_irq which exposes the new functionality.

Hopefully we can eventually remove xc_domain_bind_pt_irq. If you are
minded to you could do that today, but it's not required I think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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