On 13.11.18 08:55, Chung-Fan Yang wrote:
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?
Jailhouse focus is not on legacy. Even the IOAPIC partitioning itself is very
limited because Jailhouse has no clue (and should probably not gain it) about
how interrupts are routed to the IOAPIC - programming is too complex, too
platform-specific.
However, on all tested system, routing the on-board (legacy) UART IRQs worked
fine so far without any tricks. Is the UART for you just a debugging tool or an
operational feature? In the latter case, maybe plugging in some MSI/MSI-X
capable UART extension card is the better option.
Jan
--
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
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.
