On 2012-09-20 08:58, Abel Gordon wrote: > > > GaoYi <gaoyi...@gmail.com> wrote on 20/09/2012 08:42:51 AM: > >> The CPU isolation in Hitachi patches is just to improve the real >> time performance of GUEST. The core of it, direct IRQ delivery, is >> very similar to that of ELI. >> For the ELI patches, >> (1) Since EOI part of ELI is already supported by the Intel >> Sandy Bridge CPUs and requires modifications on GUEST code, it >> should not be included in the KVM. Only the ELI delivery part, which >> plays a vital role in performance improvement, should be considered. > > Giving to the guest direct access to the EOI MSR (if x2APIC is available) > is what we call "ELI completion". Note this mechanism is not so simple, > there are some cases (which are not part of the critical path) where ELI > must trap > EOIs. For the APLOS paper evaluation we didn't have CPUs with x2APIC so we > simulated the behavior changing the guest code. > In any case, as you can see in the paper, the big part of the improvement > comes from "ELI delivery". "ELI completion" improvement will be > even smaller with the latest KVM EOI optimizations for the memory based > LAPIC. > >> (2) It should be provided in the kvm-kmod or qemu-kvm ( not just >> for some linux kernel as Hitachi patches do), to make this part >> independent of linux kernel version. > > Exactly, ELI only modifies the kvm kernel module and qemu-kvm but we should > also modify VFIO for newer kvm versions.
Again: If you think the feature is non-invasive, send patches against the kernel and QEMU. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux