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

Re: [Xen-devel] [PATCH v3 13/24] xen/arm: Implement hypercall PHYSDEVOP_{, un}map_pirq

Hi Ian,

On 23/02/2015 16:34, Ian Campbell wrote:
On Mon, 2015-02-23 at 16:11 +0000, Julien Grall wrote:
On 23/02/15 16:04, Ian Campbell wrote:
On Mon, 2015-02-23 at 15:53 +0000, Julien Grall wrote:
Hi Ian,

On 23/02/15 15:28, Ian Campbell wrote:
On Mon, 2015-02-23 at 09:33 +0000, Jan Beulich wrote:
On 20.02.15 at 17:53, <ian.campbell@xxxxxxxxxx> wrote:
Jan, do you have any feeling for how this is going to play out on x86
with the vapic stuff?

The vapic logic shouldn't require any physdevop involvement, so if
I read right what you propose (not having such a requirement /
connection on ARM) either, I agree that a new domctl should be all
that's needed (if XEN_DOMCTL_{,un}bind_pt_irq can't be re-used).

Actually, I think bind_pt_irq with a new PT_IRQ_TYPE_* would be a good

An ARM SPI is a bit like an ISA IRQ, but not close enough to reuse IMHO
(and the datatype would need widening).

We have to think about MSI and other type too...

In any case a DOMCTL is not suitable here because a guest kernel may
need to map/unmap IRQ too (think about ACPI or device passthrough).

I don't follow, setting up device passthrough is very much a toolstack
operation, isn't it? Where does the guest kernel get involved?

Sorry I meant the DOM0 kernel.

Not really. On platform device pass-through there is no way to know the
IRQ, so for now the routing is done by the toolstack.

But we could decide to implement a driver in DOM0 which will
unbind/bind/reset device.

Sure, but...

  In this case it will require to
assign/deassign the IRQ from DOM0.

...why does that follow?

Because we may decide to re-use the device to DOM0.

In the case of the DOMCTL, it's not possible to do it.

There is also the case of MSI.

Handled via XEN_DOMCTL_bind_pt_irq for the toolstack configuration
angle, the actual guest usage of them is a separate interface which
doesn't yet concern us, at least not in this series.

That would require some rework in the toolstack to make the IRQ routing (xc_physdev...) per architecture.

Also what about IRQ permission? Should we just ignore it and not give permission to the guest domain?

As for ACPI, I think dom0 propagating ACPI derived platform info to Xen
should be handled differently (at the hypercall interface at least)
separate from passthrough.

There is no difference between routing because of ACPI and/or because
pass-through. So this should be done the same way.

I'm not convinced. Routing all the IRQs is only one aspect of dom0
propagating ACPI derived platform info to Xen.

I suppose we will see once I look at the ACPI series. In the meantime I
think XEN_DOMCTL_bind_pt_irq matches your requirements in for this
series (and is a domctl so we aren't tied to it once we have a better
understanding of the other stuff).

ACPI is one part of the problem, MSI with PCI is another problem.

Anyway, I suspect we will have the same talk before 4.6 release so we just defer the problem.


Julien Grall

Xen-devel mailing list



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