**** BEGIN LOGGING AT Tue Aug 06 02:59:57 2019
Aug 06 05:15:30 <Abhishek_1> <pratimugale[m] "abhishek_[m]: https://github.com"> pratimugale : You might want to write tests for prussd.py in that case that would run every time you push to make sure nothing breaks.
Aug 06 05:20:41 <pratimugale[m]> ok, trying it and will get back to you
Aug 06 16:44:00 <embden_new[m]> julieng:  sstabellini  is it possible to remap interrupts in usual vgic in xen or they are static?
Aug 06 17:26:29 <sstabellini> embden_new[m]: are you asking if it is possible to remap interrupts to the hypervisor?
Aug 06 17:26:44 <sstabellini> embden_new[m]: or whether Xen can remapped them to a VM?
Aug 06 17:26:54 <sstabellini> embden_new[m]: either way the answer is that it is possible :-)
Aug 06 17:27:01 <sstabellini> Xen  can remap to self or to VMs
Aug 06 17:28:47 <embden_new[m]> sstabellini: I mean is it possible for example if we assigned that irq36 is uart to remap uart later to be irq40 for example
Aug 06 17:41:32 <sstabellini> embden_new[m]: yes, it is possible to remap interrupts to different numbers to VMs. It is not possible to do so within Xen.
Aug 06 17:54:21 <embden_new[m]> julieng:  sstabellini  So what is the best way for me? I have crossbar - that is a harware mapper of 400+ irqs to 191 gic lines. We set 'em up randomly during xen start. We exposed the crossbar to dom0, so, Linux can change it and it does. For example, it writes 32 into crossbar_base+offsset_of(gic line 8) and it means that Linux wants irq32 to be mapped into gic line 8. But we already mapped it for example to line
Aug 06 17:54:22 <embden_new[m]> 4.
Aug 06 17:55:26 <sstabellini> embden_new[m]: Xen should probably wait for Linux to program the virtual crossbar (the instance you expose to dom0 by trap &  emulate) and then program the physical crossbar accordingly
Aug 06 17:55:52 <julieng> sstabellini: embden_new[m]: I don't think we can wait. We have to use it for UART0 in Xen.
Aug 06 17:56:08 <sstabellini> ah interesting
Aug 06 17:56:36 <julieng> Otherwise we could have just passthrough the crossbar to Dom0 directly ;)
Aug 06 17:57:55 <julieng> IIRC we don't require the virtual irq to match the host irq. Although, this is the case today.
Aug 06 17:58:23 <julieng> What Linux will program in the crossbar is the virtual irq
Aug 06 17:58:58 <julieng> So we could potentially allocate a host irq and route to it.
Aug 06 18:01:16 <embden_new[m]> julieng:  oh, so by virtualizing crossbar, you meant not to change the real crossbar, but change the virtual crossbar structure+vgic?
Aug 06 18:02:24 <julieng> embden_new[m]: There are various approach possible
Aug 06 18:02:24 <embden_new[m]> hm, though, you still have to change the real one
Aug 06 18:04:08 <julieng> I don't have the best appraoch ATM and you would need to explore what could be done.
Aug 06 18:04:47 <julieng> The simplest approach would be to expose exactly the same crossbar to
Aug 06 18:04:48 <julieng> Dom0 and trap all the access. Any access to registers associated to IRQs
Aug 06 18:04:50 <julieng> used by Xen would just be ignored. In this approach, we would probably
Aug 06 18:04:52 <julieng> want to update ti-irqs-skip/ti,irqs-reserved.
Aug 06 18:05:01 <julieng> sstabellini: embden_new[m] ^
Aug 06 18:06:18 <sstabellini> Yes, I think the first step is to trap everything crossbar related in Xen
Aug 06 18:06:47 <julieng> sstabellini: IIRC he is already able to trap... Now we need to decide what to do with it.
Aug 06 18:06:57 <sstabellini> ah OK good
Aug 06 18:07:52 <julieng> embden_new[m]: I would recommend to try to understand what how the Linux driver works and whether we can use the binding to tell Linux "This IRQ should not be touched".
Aug 06 18:08:18 <julieng> From a quick look at the binding, ti,irqs-skip should do the job, but I haven't tried.
Aug 06 18:08:46 <julieng> Depending of the outcome here, you can then define the best approach to get the crossbar working.
Aug 06 18:09:52 <embden_new[m]> julieng:  yeah, I updated ti,irqs-reserver for irq 4 with 0xa48 offset. And Linux started to process from irq seven as expected. But (!) it also assumed that irq7 now has 0xa48 offset. So, everything went quite wrong.
Aug 06 18:11:00 <julieng> embden_new[m]: That's expected from the binding :)
Aug 06 18:11:06 <julieng> - ti,reg-size: Size of a individual register in bytes. Every individual
Aug 06 18:11:08 <julieng>             register is assumed to be of same size. Valid sizes are 1, 2, 4.
Aug 06 18:11:10 <julieng> - ti,irqs-reserved: List of the reserved irq lines that are not muxed using
Aug 06 18:11:12 <julieng>                  crossbar. These interrupt lines are reserved in the soc,
Aug 06 18:11:14 <julieng>                  so crossbar bar driver should not consider them as free
Aug 06 18:11:16 <julieng>                  lines.
Aug 06 18:11:19 <julieng> - ti,irqs-skip: This is similar to "ti,irqs-reserved", but these are for
Aug 06 18:11:20 <julieng>   SOC-specific hard-wiring of those irqs which unexpectedly bypasses the
Aug 06 18:11:22 <julieng>   crossbar. These irqs have a crossbar register, but still cannot be used.
Aug 06 18:11:43 <julieng> (This is a copy of Documentation/devicetree/bindings/arm/omap/crossbar.txt)
Aug 06 18:12:16 <embden_new[m]> so, ti,irq-skip should work?
Aug 06 18:12:29 <embden_new[m]> I'll try
Aug 06 18:13:21 <embden_new[m]> hm, though, I still need to implement remapping
Aug 06 18:13:21 <julieng> embden_new[m]: If I understood the spec correctly then yes. But that's you to confirm it ;).
Aug 06 18:13:52 <julieng> embden_new[m]: Not necessarily. You can just look how the crossbar behave by printing the access.
Aug 06 18:14:10 <julieng> embden_new[m]: If you don't receive interrupts to the guest, it does not much matter.
Aug 06 18:14:42 <julieng> I mean in the context of the investigation suggested above.
Aug 06 18:15:05 <embden_new[m]> julieng:  by printing the access?
Aug 06 18:15:52 <julieng> embden_new[m]: You have implemented IO helper for the crossbar in Xen, right? You could add message in it to see how the driver is behaving.
Aug 06 18:16:06 <julieng> Alternatively, you can read the driver code.
Aug 06 18:18:00 <embden_new[m]> julieng: oh, yes, that's true.
Aug 06 18:24:18 <embden_new[m]> julieng:  yes, with irq skip it works right
Aug 06 18:52:24 <embden_new[m]> julieng:  sstabellini  so, the idea is to follow Linux and change interrupt numbers in vgic according to how Linux set them up?
Aug 06 18:53:01 <sstabellini> embden_new[m]: yes, unless it conflicts with something setup by Xen, in that case ignore it
Aug 06 18:53:36 <embden_new[m]> ok, I'll try to implement it till tomorrow meeting
Aug 06 18:56:45 <julieng> embden_new[m]: You should not need to change the vGIC. Unless you are looking at dealing with VIRQ = IRQ
Aug 06 18:56:52 <julieng> * VIRQ != IRQ
Aug 06 18:57:55 <julieng> The only thing you should need to change is the host crossbar configuration so the interrupt is routed correctly.
Aug 06 18:59:54 <embden_new[m]> julieng:  don't I change it by returning 1 in mmio handlers?
Aug 06 19:02:18 <embden_new[m]> I thought, that Linux has a vgic, so it is expected that if Linux routed an irq to line 7 then xen should change routing to the gic line mapped to vgic's line 7?
Aug 06 19:03:33 <embden_new[m]> julieng:  ^ (the first message is wrong, I forgot that vgic!=gic)
**** ENDING LOGGING AT Wed Aug 07 03:02:32 2019