On 02.10.2013, at 15:57, Michael Ellerman wrote: > On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote: >> On Wed, Oct 02, 2013 at 11:50:50AM +0200, Alexander Graf wrote: >>> >>> On 02.10.2013, at 11:11, Alexander Graf wrote: >>> >>> So how do you solve live migration between a kernel that has this patch and one that doesn't? >>> >> Yes, I alluded to it in my email to Paul and Paolo asked also. How this >> interface is disabled? > > Yes that is a valid point. > > We can't disable the interface at runtime, the guest detects its > presence at boot. > > What will happen is the hcall will come through to QEMU, which will > reject it with H_FUNCTION (~= ENOSYS). > > The current pseries-rng driver does not handle that case well, which is > exactly why I sent patches to fix it recently. > > The only other option would be to feed it with /dev/random. > >> Also hwrnd is MMIO in a host why guest needs to >> use hypercall instead of emulating the device (in kernel or somewhere >> else?). > > Because PAPR is a platform specification and it specifies that the > interface is a hypervisor call. We can't just decide we want to do it > differently. > >> Another things is that on a host hwrnd is protected from >> direct userspace access by virtue of been a device, but guest code (event >> kernel mode) is userspace as far as hosts security model goes, so by >> implementing this hypercall in a way that directly access hwrnd you >> expose hwrnd to a userspace unconditionally. Why is this a good idea? > > I'm not sure I follow you. > > The hwrng is accessible by host userspace via /dev/mem. A guest should live on the same permission level as a user space application. If you run QEMU as UID 1000 without access to /dev/mem, why should the guest suddenly be able to directly access a memory location (MMIO) it couldn't access directly through a normal user space interface. It's basically a layering violation. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
