On 18/10/2017 16:07, Yi Zhang wrote: > On 2017-10-18 at 11:35:12 +0200, Paolo Bonzini wrote: >>> >>> Currently, We only block the write access, As far as I know an example, >>> we now using it in a security daemon: >> >> Understood. However, I think QEMU is the wrong place to set this up. >> >> If the kernel wants to protect _itself_, it should use a hypercall. If >> an introspector appliance wants to protect the guest kernel, it should >> use the socket that connects it to the hypervisor. >> >> Paolo >> > > Thanks Paolo, > > Yes, that correctable, I will think about to switch the interface to a > hypercall, How about we keep these 2 interface together(hyper call + > ioctl)? think about that if VMM manager have some way could intercept > the guest kernel memory accessing, the page protection would like a > hardware watch point, is it an easy way to let VMM manager debug the > guest kernel? I would leave out the ioctl without a use case. It's always tricky to add APIs without a user, as the risk of bit rot is high. But if somebody comes up with a matching useful patch for QEMU or kvmtool, it's fine. > Except the interface change, could you please help to review the other > patch series? just skip the ioctl patch( patch 7). Yes, of course. Paolo
