On Wed, Oct 02, 2013 at 11:57:55PM +1000, 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. > What about other way, if guest migrates from kvm that has no this hypercall to one that has? We try to not change HW under guest during migration. > > 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. Any insights on why it was specified this what. What is special about hwrnd device that hypercall is needed to access it? I got that you didn't just decide to implement it that way :) Also what will happen if guest will find emulated hwrnd device, will it use it? > > > 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. > Regular user has no access to /dev/mem, but he can start kvm guest and gain access to the device. -- Gleb. -- 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
