* Andreas Rollbühler <[email protected]> [2017-09-07 11:19:28 +0000]:
> > > 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. Okay, fair enough. Fun thing is that it's still the delivery mode used via the x2APIC port (and everything works just fine), since there is no APIC MMIO access via MSRs. Zephyr has some comments at loapic_intr.c telling said "virtual wire mode" is there due to "uniprocessor compatibility mode". Anyway, this does not seem to be the cause of my issue. > > > > 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); Thanks, Andreas, but you're still talking about x*2*APIC. That works fine for me as well (and you might be right about the mess with position of >> 4 in my patch, thanks). What does not want to work at all is xAPIC mode there. _timer_int_handler() is simply not called in this mode, still looking why. All the parameters programming the intr. controller have been checked to be the same as under x2APIC, where it works. Let me look at the samples now, there has to be a gotcha. Thanks. > > > > > Jan > Andreas -- Gustavo Lima Chaves Intel - Open Source Technology Center -- 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.
