Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Weird qemu-nvmm problem



Le 11/03/2020 à 21:44, Chavdar Ivanov a écrit :
> On Wed, 11 Mar 2020 at 17:45, Maxime Villard <max%m00nbsd.net@localhost> wrote:
>>
>> Please CC me for issues related to NVMM, there is a number of lists where
>> I'm not subscribed.
> 
> I thought about it, but my presumption was that the problem is with
> something I haven't done properly...
> 
>>
>> My understanding is that this commit is the cause (CC ad@):
>>
>>         https://mail-index.netbsd.org/source-changes/2019/12/06/msg111617.html
> 
> Perhaps; I can say, that since early December I've had many occasions
> my Windows guests have been working OK; also my OmniOS guest -which I
> initially  could not boot after the installation - was able to run
> without any problems on the 29th of February; now I can't boot it at
> all.

The issue is more twisted than that, in fact, if the guest does something
worth a return to userland, NVMM will exit the VCPU loop, which re-allows
reschedulings.

So if you are "lucky" and are running a guest that eg regularly performs
operations that require MMIO/PIO emulation, the reschedulings occur there
implicitly. When that's not the case, you also have to be lucky that no
important kthread urgently needs to execute on the host CPU at the same
time.

That's also why the NVMM ATF tests don't fail either -- the reschedulings
implicitly occur during the returns to userland, and the runs are short-
lived, so we are basically always lucky.

Maxime


Home | Main Index | Thread Index | Old Index