Avi Kivity wrote: > Ingo Molnar wrote: > >> * Avi Kivity <[EMAIL PROTECTED]> wrote: >> >> >> >>> If you have a CONFIG_PARAVIRT guest, I believe it will always be >>> faster to run it without hardware assisted virtualization: >>> >>> - you cannot eliminate vmexits due to host interrupts >>> - a hypercall will (probably) keep being more expensive than a syscall; >>> it simply has a lot more work to do >>> - cr3 switches for CONFIG_PARAVIRT syscalls (which are necessary on >>> x86_64) will probably become very cheap with tagged tlbs >>> >>> >> but irq overhead is nothing in importance compared to basic syscall >> overhead. KVM/HVM already runs guest kernel syscalls at native speed. >> KVM/LL (or Xen) has to switch cr3s to enter guest kernel context, and >> has to switch it back to get back to guest user context. It might be >> pretty fast with tagged TLBs, but not zero-cost. >> >> > > For i386 Xen does not switch cr3 IIRC. Perhaps even not for x86_64 if > it can use the segment limits which AMD re-added (I think it does?) >
Xen setups the IDT to deliver directly to ring 1 for syscalls as you suggested. At the moment, Xen doesn't make use of the segment limits on AMD on 64bit. Currently, the guest kernel runs in ring 3 and I presume there are a good deal of assumptions about that. Xen does, however, use global pages for the kernel (and it's) memory so that should help a bit. One thing to consider though is how things like hardware nested paging and CR3 caching come into play. On a context switch, a Xen style paravirt has to use hypercalls to change CR3 (since it's privileged) whereas on VT, there's at least the chance of hitting the cache before taking a VMEXIT. Also, nested paging should considerably change the performance characteristics of a FV guest. While TLB lookups will end up being more expensive (since more memory accesses are required), the overall cost of page fault handling will go down significantly. Recall, even in direct paged mode, Xen has to take page faults in the hypervisor first. With nested paging, presumably page faults can be delivered directly to the guest[1]. [1] This assumes that the implementation will allow for physical memory holes which will result in VMEXITs (for MMIO emulation). Regards, Anthony Liguori > I think for i386 Xen does not go through the hypervisor at all: it hacks > int 0x80 to trap directly to ring 1. So there's still the overhead of > using int rather than sysenter, but not much more. I don't know how the > (many syscalls) x (smaller overhead) vs (fewer interrupts) x (greater > overhead) stack up. > > > -- > error compiling committee.c: too many arguments to function > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
