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

Re: [Xen-devel] [PATCH for-4.6 0/5] xen: arm: Parse PCI DT nodes' ranges and interrupt-map

On 19/02/15 1:43 am, Suravee Suthikulanit wrote:
On 2/18/2015 6:48 AM, Julien Grall wrote:
Hi Suravee,

On 18/02/2015 05:28, Suravee Suthikulanit wrote:

Actually, that seems to be more related to the PCI pass-through devices. Isn't the Cavium guys already done that work to support their PCI device

They were working on it, but so far there is no patch series on the ML.
It would be nice to come with a common solution (i.e between GICv2m and
GICv3 ITS) for MSI.

Agree, although for supporting Dom0 MSI, I don't see anything that could be shared since this would totally be two separate drivers/interfaces.

Anyways, at this point, I am able to generated Dom0 device tree with
correct v2m node, and I can see Dom0 gicv2m driver probing and
initializing correctly as it would on bare-metal.

# Snippet from /sys/firmware/fdt showing dom0 GIC node
     interrupt-controller {
         compatible = "arm,gic-400", "arm,cortex-a15-gic";
         #interrupt-cells = <0x3>;
         reg = <0x0 0xe1110000 0x0 0x1000 0x0 0xe112f000 0x0 0x2000>;
         phandle = <0x1>;
         #address-cells = <0x2>;
         #size-cells = <0x2>;
         ranges = <0x0 0x0 0x0 0xe1100000 0x0 0x100000>;

         v2m {
             compatible = "arm,gic-v2m-frame";
             arm,msi-base-spi = <0x40>;
             arm,msi-num-spis = <0x100>;
             phandle = <0x5>;
             reg = <0x0 0x80000 0x0 0x1000>;

linux:~ # dmesg | grep v2m
[    0.000000] GICv2m: Overriding V2M MSI_TYPER (base:64, num:256)
[    0.000000] GICv2m: Node v2m: range[0xe1180000:0xe1180fff],

So, during setting up v2m in hypervisor, I also call
route_irq_to_guest() for the all SPIs used for MSI (i.e. 64-320 on
Seattle), which will force the MSIs to Dom0. However, we would need to
figure out how to detach and re-route certain interrupts to a specific
DomU in case of passing through PCI devices in the future.

Who decide to assign the MSI n to the SPI x? DOM0 or Xen?

For v2m, each MSI is tied to a specific SPI. The range of SPIs is specified in the GIC V2M_MSI_TYPER register. In Xen, we need to make sure that these are routed to Dom0 initially since Dom0 GICv2m driver is the one handling all MSI assignments.

Wouldn't it be possible to route the SPI dynamically when the domain
decide to use the MSI n? We would need to implement PHYSDEVOP_map_pirq
for MSI.

Enabling MSI is done by each end-point PCI device drivers in the guest. In Linux, this would mean that when the driver tries to allocate an MSI interrupt, it would need to communicate back to Xen (possibly via hypercall as you pointed out) to get the next available SPI. It is not necessary for now. I am planning to revisit this when we try to implement pass-through support. Lemme know if you think this should be handled differently.

For cavium we are doing it differently. In the frontend bus we have added its. I am planning to send RFC patches soon.


Xen-devel mailing list

Xen-devel mailing list



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