Re: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Tue, Jun 9, 2020 at 5:53 PM Tian, Kevin <kevin.tian@xxxxxxxxx> wrote:
>
> > From: Tian, Kevin
> > Sent: Wednesday, June 10, 2020 7:44 AM
> >
> > > From: Lengyel, Tamas <tamas.lengyel@xxxxxxxxx>
> > > Sent: Monday, June 1, 2020 9:22 PM
> > >
> > > When running VM forks without device models (QEMU), it may
> > > be undesirable for Xen to inject interrupts. When creating such forks from
> > > Windows VMs we have observed the kernel trying to process interrupts
> > > immediately after the fork is executed. However without QEMU running
> > such
> > > interrupt handling may not be possible because it may attempt to interact
> > > with
> > > devices that are not emulated by a backend. In the best case scenario such
> >
> > I asked this question before. the interrupts could come from Xen itself, 
> > e.g.
> > due to timer virtualization. So I didn't get why it's desired to block all
> > interrupts
> > just because no QEMU is running. Also it's weird why Windows VMs are
> > observed to process interrupts that are generated by QEMU when no such
> > backend emulation exists at all. It sounds like a workaround instead of a 
> > real
> > fix...
>
> ok, I rechecked your reply. Looks it's about the case that parent VM has QEMU
> and pending interrupts while you fork it into child VMs without QEMU so those
> pending interrupts become problematic.
>
> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>

HI Kevin,
thanks! That's the case but really we just want to block all
interrupts irrespective of where the are coming from. The fork VMs are
being reset hundreds or thousands of times per second during fuzzing,
so there is no point in injecting any interrupt at all in that
particular use-case.

Tamas