but since the host still has to perform some paging (and possibly for the guest) in paravirt, it should affect guest performance. In this snippet I think that is paravirt guest code so page tables don’t need to be isolated twice.
So I think the host kernels’ perf degredation will still affect it.
No, I actually meant multiplicative. I was worried that the worst case is 30% syscall overhead on virtualization host multiplied by 30% syscall overhead on virtualization guest.
Still, even if this mitigation is only enabled on Xen host and not on the guest, can this attack be then used inside the guest's userspace to read memory of the guest's kernel, as opposed to reading memory of the host's kernel?
The form of the overhead is doing a set amount of extra work per syscall. It's hard for me to picture any way that could multiply. The extra work doesn't change based on how long the syscall takes.
I’ve been wondering the same thing. I think it depends on how/if the hypervisor tries to “emulate” speculative execution on some calls or instructions. If it does and does so faithfully, then perhaps. My guess though is that such emulated functionality would be missing this bug.
So I think the host kernels’ perf degredation will still affect it.