On 2017-09-07 02:42, Gustavo Lima Chaves wrote: > * Gustavo Lima Chaves <[email protected]> [2017-09-06 21:42:37 > +0000]: > >> * Jan Kiszka <[email protected]> [2017-09-01 18:32:54 +0000]: >> >>> On 2017-09-01 20:08, Gustavo Lima Chaves wrote: >>>> Hi. >>>> >>>> I'm already experimenting with this issue, in the way of trying to get >>>> Zephyr + xAPIC good to go, besides x2APIC, but here goes the doubt in >>>> order to confirm it. >>>> >>>> The function in the subject, which offloads work to apic_mmio_access() >>>> and then to x86_mmio_parse(), has this last one parse the instruction >>>> doing APIC mem. region access in order to intercept the access and >>>> either put or take a value to/from that memory into a register. >>>> >>>> Some MOV variants are covered there, but we are *very far* from having >>>> any reasonable coverage in that list. For instance, all the parsing >>>> code assumes the from/to places (other than the APIC mem. region) are >>>> always registers—at least that's what I understand now. What about >>>> memory regions and immediate values? >>>> >>>> Zephyr generates code using different MOVs to access the APIC mem. >>>> region and I'm filling up that list + parsing code with more info >>>> trying to capture that. >>>> >>>> Am I wrong in any point? >>> >>> Jailhouse implements support for emulating only very few instructions, >>> because this can easily explode the code size. Basically, we just >>> support what Linux needs and define that all other guests should >>> restrict themselves to those instructions. That's also why there are >>> MMIO accessors in the libinmate. >>> >>> Now one may argue about adding one or two more simple mov instructions >>> to the emulator if it really helps, we did that before, but I do not >>> want to expand beyond that. >> >> Ok, that's the case anyway, some number around that. >> >>> >>> The proper answer to that issue would be hardware support for >>> instruction parsing, just like other archs have. It's really lame that >>> MMIO interception requires so much effort in software. >> >> I agree, such pain to parse that as well. Now for something different: >> why allowing only fixed and NMI delivery modes for APIC on guests? Is >> ExtINT detrimental in any way? That's what Zephyr uses... > > And that might explain why I reach my Zephyr application's main > function but the programmed timers won't fire (under xAPIC).
We don't support ExtINT because A) that's the old-fashioned way to program the system and B) it requires knowledge about the external wiring to the corresponding processor pin in order to make an educated decision if a particular core is allowed to use that mode or would disturb others when doing so. Can't we modernized Zephyr instead? I haven't received such a request before, even when folks ported way older RTOSes over Jailhouse. Andreas, how did you address this? Or don't you use software timers yet? Jan -- Siemens AG, Corporate Technology, CT RDA ITP 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
