New version turns Meltdown mitigation into a feature
It was actually the other way round: a feature we already worked on, happened to be useful as a Meltdown mitigation. But the effect is the same.
The Xen Project last week sent the first release candidate of Xen 4.11 down the slipway, ahead of a few weeks’ testing and a planned release on June 1st, 2018. To help you understand what will land on that day, The Register asked Lars Kurth, chair of the Xen Project Advisory Board for his views on what’s important and new in …
So the good part of Xen which was always PV is now bad due to specter. You can transparently run your PV in a HVM, or you can rely on a new unnamed guest container to harden your PV.
Is that what your saying? Reading the article I felt was a jargon spin cycle with a container thrown in.
> So the good part of Xen which was always PV is now bad due to specter.
No, Spectre impacts HVM/PVH and PV equally and the same mitigations apply to each. You could argue that Meltdown has made PV less performant for some workloads. But the reality is that on most modern Hardware HVM and PVH have higher performance compared to PV for almost all workloads. Thus, many hosting/cloud providers only offer HVM/PVH guests for new instances. Now PVHVM for example, despite it's name is actually a HVM guest.
What hosting providers will gain is the option to support old PV guests (unmodified) running in a PVH container in a HVM/PVH container in a Hypervisor that is half the size (which is significant from a security perspective).
Conversely, you will also have the option of building a PV Xen only, if that is what you want. And there are use-cases where that makes sense.
> Reading the article I felt was a jargon spin cycle with a container thrown in.
Have a look at https://www.slideshare.net/xen_com_mgr/xpdss17-keynote-secure-containers-with-xen-and-coreos-rkt-stefano-stabellini-aporeto ... the development has moved on somewhat since then, but this gives you the ghist