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. 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. 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.
