2018年11月12日月曜日 16時34分08秒 UTC+9 Chung-Fan Yang: > 2018年11月12日月曜日 15時10分30秒 UTC+9 Chung-Fan Yang: > > 2018年11月10日土曜日 16時25分57秒 UTC+9 Jan Kiszka: > > > On 09.11.18 09:02, Chung-Fan Yang wrote: > > > > 2018年10月8日月曜日 19時23分52秒 UTC+9 J. Kiszka: > > > >> On 05.10.18 09:52, Chung-Fan Yang wrote: > > > >>> 2018年10月5日金曜日 16時18分41秒 UTC+9 Chung-Fan Yang: > > > >>>> 2018年10月4日木曜日 18時13分50秒 UTC+9 Jan Kiszka: > > > >>>>> On 04.10.18 10:46, Chung-Fan Yang wrote: > > > >>>>>> Hello, > > > >>>>>> > > > >>>>>> I am using jailhouse to run a RTOS(nuttx) on a Xeon E5-2630 v4 > > > >>>>>> machine. > > > >>>>>> I am currently trying to implement interrupt driven seril output. > > > >>>>>> Therefore, I tried to remap the IRQ4, which is the ttyS0's IRQ, to > > > >>>>>> the RTOS. > > > >>>>>> > > > >>>>>> I try to mimic IOAPIC demo's procedure of reampping ACPI IRQ to > > > >>>>>> remap IRQ4. > > > >>>>>> The IOAPIC demo works fine, but not when I use the same technique > > > >>>>>> to remap IRQ4, the following error message is printed on the > > > >>>>>> jailhouse console(ttyS1). > > > >>>>>> > > > >>>>>> VT-d fault event reported by IOMMU 1: > > > >>>>>> Source Identifier (bus:dev.func): f0:1f.7 > > > >>>>>> Fault Reason: 0x26 Fault Info: 6a000000000 Type 0 > > > >>>>>> > > > >>>>>> I try to read the VT-d manual, but I can't quite get the point why > > > >>>>>> this is happening. So I would kindly to ask help here. I have > > > >>>>>> attached the sysconfig and RTOS's config. > > > >>>>> > > > >>>>> You need to align the ID of the IOAPIC in the non-root cell config > > > >>>>> with the root > > > >>>>> cell. That's 0x1f0ff in your case. > > > >>>>> > > > >>>>> Jan > > > >>>> > > > >>>> Thank you. This do the trick. The error is gone. > > > >>>> > > > >>>> However, the interrupt is not triggered on CPU when 16550 asserted > > > >>>> it (polling IIR register reveals there was an interrupt). > > > >>>> I mapped pin 4 of IOAPIC to vector number 36 of the LAPIC, using the > > > >>>> same technique in ioapic-demo. > > > >>>> It seems like pin 4 was always high, although 16550 should be > > > >>>> sending edge triggering signals. > > > >>>> > > > >>>> I am wondering that my board has a different connection from 16550 > > > >>>> to the IOAPIC, which is unlike traditional XT-PIC, but not so sure. > > > >> > > > >> Does Linux (as non-root cell) work with that UART normally? Testing > > > >> that would > > > >> allow us to exclude the Jailhouse cell configuration from the equation. > > > >> > > > >>>> > > > >>>> Yang > > > >>> > > > >>> I didn't find the MADT table in the /sys/firmware/acpi, assuming my > > > >>> baord firmware is missing it. > > > >> > > > >> The non-root cell does not have ACPI - or is that when looking at the > > > >> root cell? > > > >> > > > >>> According to the BIOS config, COM1 is at 0x3f8 with IRQ=4. > > > >>> I tried to map IRQ 1~7, none of them works. IRQ 9 is indeed PM timer. > > > >>> This is starnge. Where did that UART IRQ go? > > > >> > > > >> Unless you have some special embedded SoC, it will be IRQ 4. Again, > > > >> testing with > > > >> Linux as non-root guest can help to isolate reasons. > > > >> > > > >> Jan > > > >> > > > >> -- > > > >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE > > > >> Corporate Competence Center Embedded Linux > > > > > > > > Hi Jan, > > > > > > > > Finally have some time back to this issue. > > > > > > > > I have built a bzImage using the patched linux source tree. > > > > Following: jailhouse/Documentation/non-root-linux.txt > > > > > > > > I use it to boot the non-root linux with the appended cell config. > > > > > > > > The kernel boot dmesg did print on tty0, but it crashes at some point. > > > > > > > > Hypervisor give the following message (I did some modification on the > > > > verboseness of the debug message): > > > > > > > > Cell "linux-x86-demo" can be loaded > > > > CPU 1 received SIPI, vector 100 > > > > CPU 2 received SIPI, vector 100 > > > > CPU 3 received SIPI, vector 100 > > > > Started cell "linux-x86-demo" > > > > CPU 2 received SIPI, vector 9a > > > > CPU 3 received SIPI, vector 9a > > > > FATAL: Invalid PIO read, port: 87 size: 1 > > > > > > That's likely due to CONFIG_ISA_DMA_API being enabled in your non-root > > > kernel. > > > > > > Jan > > > > > > > Name: linux-x86-demo > > > > RIP: 0xffffffff8354b6ee RSP: 0xffff9acec003beb0 FLAGS: 246 > > > > RAX: 0x0000000000000000 RBX: 0xffffffff8354b6ee RCX: 0x0000000000000000 > > > > RDX: 0xffff9863c24d0000 RSI: 0x0000000000000000 RDI: 0xffffffff8354b6ee > > > > CS: 10 BASE: 0x0000000000000000 AR-BYTES: a09b EFER.LMA 1 > > > > RBP: 0x00000000ffffffff > > > > DS: 0 > > > > SS: 0 > > > > GDTR_BASE: 0xfffffe0000001000 GDTR_LIMIT: 0x000000000000007f > > > > IDTR_BASE: 0xfffffe0000000000 IDTR_LIMIT: 0x0000000000000fff > > > > CR0: 0x0000000080050033 CR3: 0x000000000400a001 CR4: 0x00000000003626f0 > > > > EFER: 0x0000000000000d01 > > > > CPL: 0 RPL: 0 > > > > Parking CPU 1 (Cell: "linux-x86-demo") > > > > > > > > No idea what happened. Any suggestions? > > > > > > > > Yang > > > > > > > > Hi Jan, > > > > Thanks for the help, that did the trick. I can boot a non-root Linux with > > your patched kernel and a buildroot cpio image. > > > > However, I am observing something strange. > > > > The non-root cell reported the following during boot: > > [ 0.839162] serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) > > is a 16550A > > > > which has irq 0, on the other hand the root Linux reports with irq 4 > > > > [ 1.802724] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled > > [ 1.823389] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a > > 16550A > > [ 1.844215] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a > > 16550A > > > > But the UART still works and I can login and read /proc/interrupts, which > > the tty interrupt is missing. > > > > # cat /proc/interrupts > > CPU0 CPU1 CPU2 > > NMI: 0 0 0 Non-maskable interrupts > > LOC: 735 1028 12298 Local timer interrupts > > SPU: 0 0 0 Spurious interrupts > > PMI: 0 0 0 Performance monitoring interrupts > > IWI: 0 0 0 IRQ work interrupts > > RTR: 0 0 0 APIC ICR read retries > > RES: 89 26 45 Rescheduling interrupts > > CAL: 81 74 90 Function call interrupts > > TLB: 0 0 0 TLB shootdowns > > TRM: 0 0 0 Thermal event interrupts > > THR: 0 0 0 Threshold APIC interrupts > > DFR: 0 0 0 Deferred Error APIC interrupts > > MCE: 0 0 0 Machine check exceptions > > MCP: 1 2 2 Machine check polls > > ERR: 0 > > MIS: 0 > > PIN: 0 0 0 Posted-interrupt notification event > > NPI: 0 0 0 Nested posted-interrupt event > > PIW: 0 0 0 Posted-interrupt wakeup event > > > > I did notice that in non-root-linux.txt documentation. It said the patched > > kernel used polling for UART, but I cannot find the exact commit ID, so I > > cannot be sure that this phenomenon is expected. > > > > P.S. During boot, sometimes the hypervisor would report the following, but > > the non-root cell can still boot and be functional. > > > > VT-d fault event reported by IOMMU 1: > > > > Source Identifier (bus:dev.func): f0:1f.7 > > > > Fault Reason: 0x26 Fault Info: 6a000000000 Type 0 > > OK. I found the fault. Everything is working as expceted now. > I forget to match the IO-APIC id in the configs. > > dmesg now reports: > [ 1.119161] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) > is a 16550A > [ 1.399147] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) > is a 16550A > > /proc/interrupts now reports: > 4: 1170 0 0 IO-APIC 4-edge ttyS0 > > Everything is working find, including the legacy ioapic interrupts. > Now, I do think I really messed up something in my RTOS code. > > Yang.
Alright, I some how figured it out, partially. In x86_64 systems, the 8259 PIC is usually connected to pin0 of IOAPIC and LINT0 of LAPICs (referring old PCH manual). This is called virtual wired mode. In virtual-wired mode, either IOAPIC pin0 or LINT0 should be enabled and set to ExtINT mode, allowing CPU use legacy way to query PIC for IRQ number. I cannot get the legacy 8259 IRQs out of this virtual wired mode. Therefore, all of them will assert pin0 of IOAPIC. On the other hand PM timer is not effected, at is a modern GSI connected to IO-APIC. I wrote some code and hook the legacy IRQs to pin0, now everything works. The only downside is that I have to demux the 15 legacy IRQs in software, because Jailhouse cannot accept setting IO-APIC to ExtINT mode. It's kinda ugly, but works. Does anyone knows how to properly route the legacy IRQs to the IOAPIC? Will Jailhouse support interrupts types other than fixed? Yang. -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
