
Vixen: A PV-in-HVM shim - captainkrtek
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00436.html
======
darren0
PV in HVM, not to be confused with PV on HVM [1] which includes PVHVM and HVM
+ PV drivers :)

[1] [https://wiki.xen.org/wiki/PV_on_HVM](https://wiki.xen.org/wiki/PV_on_HVM)

~~~
snvzz
It sure gets complicated.

[https://wiki.xen.org/wiki/Virtualization_Spectrum#The_paravi...](https://wiki.xen.org/wiki/Virtualization_Spectrum#The_paravirtualization_spectrum)

------
aliguori
We're still working the details out upstream but the TL;DR is that the way to
address Meltdown with Xen PV is to use nested virtualization so that the outer
guest is an HVM or PVH guest.

~~~
jlgaddis
Is this what AWS is doing?

~~~
aliguori
Yes, all customer PV instances in EC2 are running in an HVM container and are
protected against the guest-to-guest Meltdown vulnerability.

As with all virtual and physical machines, patches are necessary to protect
against process-to-process Meltdown within the OS itself. Those are starting
to roll out from the respective vendors although it will take time for those
to work inside a PV instance.

~~~
Vogtinator
Doesn't this still allow to read memory from the hypervisor shared between the
PV VMs in a HVM container?

~~~
cthalupa
The intention, from my understanding, is not to boot multiple PV guests inside
of one HVM shim, but instead treat it as more of a packaged deal - for each PV
guest, you will be running it inside an independent vixen shim. So 5 PV
guests, 5 vixen shims, etc.

~~~
quanstro
correct.

