|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |