On 2017-08-22 19:17, Gustavo Lima Chaves wrote: > * Jan Kiszka <[email protected]> [2017-08-22 23:04:35 +0000]: > >> On 2017-08-22 13:15, Gustavo Lima Chaves wrote: >>> * Gustavo Lima Chaves <[email protected]> [2017-08-22 16:36:54 >>> +0000]: >>> >>>> * Henning Schild <[email protected]> [2017-08-22 13:42:22 +0000]: >>>> >>>>> Am Mon, 21 Aug 2017 18:13:35 -0700 >>>>> schrieb Gustavo Lima Chaves <[email protected]>: >>>>> >>>>>> Hi, >>>>>> >>>>>> is testing xAPIC mode just a matter of having >>>>>> >>>>>> diff --git a/configs/qemu-vm.c b/configs/qemu-vm.c >>>>>> index e5a420a..6225be9 100644 >>>>>> --- a/configs/qemu-vm.c >>>>>> +++ b/configs/qemu-vm.c >>>>>> @@ -49,6 +49,7 @@ struct { >>>>>> .pci_mmconfig_end_bus = 0xff, >>>>>> .x86 = { >>>>>> .pm_timer_address = 0x608, >>>>>> + .apic_mode = >>>>>> JAILHOUSE_APIC_MODE_XAPIC, .vtd_interrupt_limit = 256, >>>>>> .iommu_units = { >>>>>> { >>>>>> >>>>>> ? If so, it gives me a segv right away, with >>>>>> >>>>>> Initializing Jailhouse hypervisor v0.7 (36-g0b1b884-dirty) on CPU 3 >>>>>> Code location: 0xfffffffff0000060 >>>>>> Using xAPIC >>>>>> Page pool usage after early setup: mem 44/1480, remap 65/131072 >>>>>> Initializing processors: >>>>>> CPU 3... (APIC ID 0) FAILED >>>>>> >>>>>> as output. >>>>>> >>>>>> Has anyone been testing that? >>>>> >>>>> Just talked to Andreas, he booted his root Linux in xapic mode to >>>>> inherit that for the non-root cell. Just add "nox2apic" to your host >>>>> Linux parameters. >>>> >>>> Interesting, because my issue was at jailhouse enable time, I did not >>>> even enter the merit of which inmate payload was used. But I'll check >>>> better what's happening, if the .apic_mode = 1 approach is really all >>>> that is needed. >>> >>> Gotta hate answering to emails before coffee. You said *base* kernel, >>> sorry. Will re-test. >> >> Exactly: If the root Linux was brought up in xAPIC mode, Jailhouse has >> to follow this. Same in case it was using x2APIC before. We cannot >> switch the mode safely, so we follow what was configured before (auto >> mode) or defined in the config (like in your case). > > Thanks. It indeed wors for, say, apic-demo.c inmate. But I see code > paths there that are hardcoded (at least seem, please correct me) to > using x2APIC access—int_init() is one of them. I thought it had > infrastructure for everything APIC be twofold, not just > apic_ops.read/write. I ask that because I'd like to be able to work on > xAPIC in Zephyr as well (x2APIC mode being a separate patch), but the > world crashed for me while trying.
Jailhouse emulates the right physical APIC access for non-root cells. That's why the apic-demo only does x2APIC accesses: they are trapped and run as xAPIC in case the host is in that mode. > > Speaking of that, I used to replicate Jailhouse's prink() (via vmcall > number 8) just fine on Linux to debug things without a console, but > I'm having a hard time doing that on Zephyr (now on 32-bits). Any > clues? Hmm, the hypercall interface should be 32/64-bit agnostic. 1st check: Does the call reach the hypervisor? 2nd check: What do the registers contain? Both can be done by instrumenting the hypervisor. Alternatively, you could play with the 32-bit demo cell an configure it to use the debug console (see Documentation/debug-output.md). Jan -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
