On 20.04.2020 16:15, Tamas K Lengyel wrote: > On Mon, Apr 20, 2020 at 1:45 AM Roger Pau Monné <[email protected]> wrote: >> >> On Fri, Apr 17, 2020 at 10:06:31AM -0700, Tamas K Lengyel wrote: >>> When a forked VM is being reset while having vm_events active, re-copying >>> the >>> vCPU info page can lead to events being lost. This seems to only affect a >>> subset of events (interrupts), while not others (cpuid, MTF, EPT) thus it >>> was >> >> I'm slightly lost by the sentence, is the guest or the hypervisor >> the one losing events? >> >> Ie: interrupts are events from a guest PoV, but cpuid or EPT is not >> something that triggers events that are injected to the guest. I think >> the commit message needs clarification. > > Sorry, what I meant was software interrupts are not triggered anymore, > ie. int3 and it's associated event is not sent to the monitor > application (VM_EVENT_REASON_SOFTWARE_BREAKPOINT). > >> >>> not discovered beforehand. Only copying vCPU info page contents during >>> initial >>> fork fixes the problem. >> >> Hm, I'm not sure I understand why this is causing issues. When you >> reset a fork you should reset the vcpu info page, or else event masks would >> be in a wrong state? > > When we reset a fork we only want to 1) discard any memory allocated > for it 2) reset the vCPU registers. We don't want to reset event > channels or anything else. We have active vm_events on the domain and > the whole point of doing a fork reset is to avoid having to > reinitialize all that as it's quite slow.
So for an arbitrary piece of state, what are the criteria to establish whether to copy or re-init them during a fork? Is it really now and forever only memory that wants resetting? I have to admit I'm confused by you also mentioning CPU registers - aren't they to be copied rather than reset? Jan
