On 21/03/2019 18:39, Andy Lutomirski wrote: > On Thu, Mar 21, 2019 at 11:37 AM Peter Zijlstra <pet...@infradead.org> wrote: >> On Thu, Mar 21, 2019 at 11:25:44AM -0700, Linus Torvalds wrote: >>> On Thu, Mar 21, 2019 at 11:21 AM Andy Lutomirski <l...@kernel.org> wrote: >>>> I dunno. Lots of people at least use to have serious commercial interest >>>> in it. >>> Yes, it used to be a big deal. But full virtualization has gotten a >>> lot more common and better. >>> >>>> Hey Xen folks, how close are we to being able to say "if you want to >>>> run a new kernel, you need to switch to PVH or similar"? >>> I'd also like to know if we could perhaps at least limit PV to just >>> the thing that people care most deeply about. >>> >>> For example, maybe people notice that they really deeply care about >>> the PV spinlocks because they help a lot for some loads, but don't >>> care so much about the low-level CPU PV stuff any more because modern >>> CPUs do _those_ things so well these days. >>> >>> So it might not be an all-or-nothing thing, but a gradual "let's stop >>> supporting xyz under PV, because it causes pain and isn't worth it". >> So Juergen recently introduced PARAVIRT_XXL, which are exactly those >> bits of PV we can get rid of. >> >> This paravirt-me-harder config does indeed include the CR2 bits. >> >> I recently talked to Andrew Cooper about this, and he said Xen Dom0 >> still needs all this :/ > There were patches from last year to fix that: > > https://lwn.net/Articles/753982/ > > I have no clue what the status is.
I'm sorry to say that Xen PV is not going to die any time soon (as far as Xen is concerned). For customer VMs, using the VT-x/SVM hardware extensions is definitely the way to go, but for host level operations, the difference between syscall vs vmexit, or (not) having to do an EPT flush make an overwhelming difference in performance. Our PVH virtualisation mode, including for dom0, is making good progress. With Xen 4.12 and Linux 4.19+, a lot of basic functionality now does work. However, we've got 15 years of legacy problems to try and untangle while doing this, including (but not limited to) Linux (rather than Xen) being OSPM, or the fact that using virtual addresses for hypercalls and mappings should never have propagate beyond the PV ABI when HVM came along. Even with the legacy API/ABI issues fixed, the straight performance difference between root mode operations, and vmexits, means that it is by no means a certainty that a PVH dom0 will be the best option for systems to use. I'm afraid that I've not got the original context of this thread, but I'm going to guess that something is resulting in a #PF before %cr2 before it gets saved on the #PF path, and using a PVOP causes things to explode? If it helps in the short term, Xen will trap and emulate a mov from cr2 instruction correctly. Performance will surely suck, but it might be an option if we need to rethink how this information is made available to guests. Thanks, ~Andrew
