On Mon, May 25, 2020 at 7:06 AM Jan Beulich <jbeul...@suse.com> wrote: > > On 25.05.2020 14:18, Tamas K Lengyel wrote: > > On Mon, May 25, 2020 at 12:06 AM Jan Beulich <jbeul...@suse.com> wrote: > >> > >> On 22.05.2020 18:33, Tamas K Lengyel wrote: > >>> When running shallow forks without device models it may be undesirable > >>> for Xen > >>> to inject interrupts. With Windows forks we have observed the kernel > >>> going into > >>> infinite loops when trying to process such interrupts, likely because it > >>> attempts > >>> to interact with devices that are not responding without QEMU running. By > >>> disabling interrupt injection the fuzzer can exercise the target code > >>> without > >>> interference. > >>> > >>> Forks & memory sharing are only available on Intel CPUs so this only > >>> applies > >>> to vmx. > >> > >> Looking at e.g. mem_sharing_control() I can't seem to be able to confirm > >> this. Would you mind pointing me at where this restriction is coming from? > > > > Both mem_access and mem_sharing are only implemented for EPT: > > http://xenbits.xen.org/hg/xen-unstable.hg/file/5eadf9363c25/xen/arch/x86/mm/p2m-ept.c#l126. > > p2m-pt.c:p2m_type_to_flags() has a similar case label.
It doesn't do anything though, does it? For mem_sharing to work you actively have to restrict the memory permissions on the shared entries to be read/execute only. That's only done for EPT. > And I can't > spot a respective restriction in mem_sharing_memop(), i.e. it looks > to me as if enabling mem-sharing on NPT (to satisfy hap_enabled() > in mem_sharing_control()) would be possible. If you are looking for an explicit gate like that, then you are right, there isn't one. You can ask the original authors of this subsystem why that is. If you feel like adding an extra gate, I wouldn't object. Tamas
