On 02/07/2020, 'Nikhil Devshatwar' via Jailhouse <[email protected]> wrote: > > > On 02/07/20 5:14 pm, Jan Kiszka wrote: >> On 02.07.20 12:03, Peng Fan wrote: >>> Hi Jan >>> >>> https://events19.linuxfoundation.org/wp-content/uploads/2018/07/Consolidate-Real-Time-and-HMI-with-ACRN-Hypervisor.pdf >>> >>> >>> >>> Have you ever see this? Page 13, there is a compare between ACRN and >>> jailhouse on X86. >>> >>> So it show ACRN a bit better? But is there any big differences in >>> design? I doubt this. >>> >> >> You also need to read the paper where the stats came from: They >> implemented APIC (GIC equivalent) pass-through also in ACRN, a feature >> that Jailhouse introduced in 2013, and then tried to compare that two >> Jailhouse and also RT-KVM. Unfortunately, there were configuration >> mistakes in both of those other setup. The one in Jailhouse they found >> themselves, redid the measurements, unsurprisingly found both to be the >> same then (no hypervisor involved anymore), but they didn't update their >> graphs, even not in the paper. The graphs where simply copied into that >> presentation. >> >> I attended that session and offered the presenter afterwards to review >> their results in the future if those are taken over a stack they are not >> familiar with. That would have also helped to avoid the architectural >> mistake in their RT-KVM measurement setup which gave them result of by >> one order of magnitude. >> >> BTW, regarding direct interrupt delivery on ARM: In >> https://lwn.net/Articles/820830, it is reported that Bao has "found a >> way to map interrupts directly into guests". I didn't find the time yet >> to check if that is actually exit-free delivery, and that as a smart >> trick or rather a problematic hack. Or if that sentence is rather a >> misunderstanding. There is also the sentence: "Interrupts [...] have to >> be mediated through the hypervisor, which is unfortunate since that >> increases latency." >> > > I found this interesting and tried to read more about this. > I found some commits at [1] which does the direct injection. > Here is my rough understanding: > > * He is not setting the HCR_EL.FMO bit and that way all virtual > interrupts are turned off > * There is a new handler for handling "lower_el_aarch64_fiq" > which ends up being handled by the Hypervisor > * GICD is still being emulated so guests won't be able to route > interrupts to wrong CPUs. Isolation is maintained > * For triggering interrupts from Hypervisor (SGIs, etc) he is using SMC > calls and has a new service implemented in the ATF [2] > * I could not understand how the lower_el_aarch64_fiq exception is fired > so that the Hypervisor is invoked > > My guess is that most of the code change ihere s to enable interrupts in > the Hypervisor. Resetting HCR_EL2.FMO would send the interrupts at EL1 > directly.
Yup, that's more or less it. Just one clarifications, Bao *does* set the HCR_EL2.FMO, it doesn't set the HCR_EL2.HMO. The HMO bit lets the interrupts through, and they go directly to EL1/0. The virtual machines have complete access to the gicc and receive IRQs without overhead. As you have already pointed out, gicd is still emulated, so all the operation of "enable/disable/set_tarrget" are slow as usual, and still under control of the hypervisor. The problem is that IRQs are completely invisible to EL2, so Bao needs to use FIQs for its internal functions. And to do that the only way is to go through the secure monitor in EL3 for each operation, having custom services running in the arm trusted firmware. I've even thought of trying something similar in jailhouse, using the linux driver that, running in EL1, could let jailhouse access the IRQs even without the HMO bit set, and therefore allowing direct IRQs access to inmates without the need to put a custom service in the arm trusted firmware, but I found it a bit too intricate. -- Angelo > > [1] > https://github.com/bao-project/bao-hypervisor/commit/ac41859fc26df8cbb16b25ca949f07f00c1d35a5 > [2] > https://github.com/bao-project/bao-hypervisor/commit/0aaa1cade8b5e846503e9b515ae278cfeda30a8b > > Nikhil D > >> 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jailhouse-dev/e0b6c5f5-89a0-6e29-6700-e5d5064d4672%40ti.com. > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/CADiTV-0qHuXt%3DwrGCp4RbFWcu%3DWGsZKB-doXOTxjMVZkRiiiCA%40mail.gmail.com.
