On 07.09.2017 07:08, Jan Kiszka wrote:
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?
I use the loapic timer but I didn't change the delivery modes in the
entries
of the local vector table.
On issue I changed is how to address the entries in the lvt:
diff --git a/drivers/interrupt_controller/loapic_intr.c
b/drivers/interrupt_controller/loapic_intr.c
index 800bda7..c897c20 100644
--- a/drivers/interrupt_controller/loapic_intr.c
+++ b/drivers/interrupt_controller/loapic_intr.c
@@ -375,8 +375,8 @@ void _loapic_int_vec_set(unsigned int irq, /* IRQ
number of the interrupt */
#ifndef CONFIG_JAILHOUSE
*pLvt = (*pLvt & ~LOAPIC_VECTOR) | vector;
#else
- tmp = (read_x2apic((LOAPIC_TIMER >> 4) + (irq * 0x10)));
- write_x2apic((LOAPIC_TIMER >> 4) + (irq * 0x10),
+ tmp = (read_x2apic((LOAPIC_TIMER + (irq * 0x10)) >> 4));
+ write_x2apic((LOAPIC_TIMER + (irq * 0x10)) >> 4,
(tmp & ~LOAPIC_VECTOR) | vector);
#endif
irq_unlock(oldLevel);
Jan
Andreas
--
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.
