[mythtv-users] mythbackend in a KVM VM (thread started out as "in docker container")

[Stephen Worthington]

On Thu, 23 May 2024 14:10:34 +0100, you wrote:

>Thanks for the continued help.
>
>On 23/05/2024 02:29, Stephen Worthington wrote:
>> On Wed, 22 May 2024 17:05:16 +0100, you wrote:
>> 
>>> Yes, it wasn't minisatip I was suspecting as the core of the problem. I
>>> was thinking that the tuner drivers may be failing to react to
>>> interrupts fast enough because of the virtualisation overheads. When you
>>> were running minisatip on that old system, was it running under a VM or
>>> was that old system acting as a host for other software running in VMs
>>> symultaneously with running minisatip?
>> 
>> My main MythTV box does not normally also run VMs.  I do occasionally
>> run a VirtualBox VM on it, with a basic Windows 10 inside, to allow me
>> to run the software to configure my Corsair RM650i power supply via a
>> USB connection.  I have run that VM at times when the box is busy in
>> the middle of the evening (running multiple recordings), and I believe
>> I would have noticed if there was a problem with recordings done then.
>
>But did you do that with that back when you were running a much older 
>system?

Yes, for many years.  The RM650i power supply is quite old now - it
replaced a Zalman power supply that died about half way through the
life of the old M5A97 EVO motherboard, so likely nearly 6 years ago.

>> The idea that the data loss is coming from slow response to interrupts
>> in the VM would only apply when running the tuners in the VM.  It
>> would not affect using SAT>IP tuners where the drivers are running in
>> the normal system environment.
>
>I wondered if there might be overheads just because the system was 
>hosting VMs that might sometimes add a little extra latency to the 
>handling of interrupts. There would be in a single CPU system because on 
>occasion the CPU would have to change context to service the interrupt, 
>but you likely know more how it all works than I do.

In any decent CPU from the last 15? 20? years, the extra time taken to
do a context switch for an interrupt is not likely to cause a problem
with a driver on the host system.  If it was possible, then the tuner
hardware and driver would need to be designed in a way that worked if
that happened, otherwise the product would not be fit for purpose. The
usual fix would be to have some extra buffering in the tuner hardware.

Inside a VM, it really depends on how the VM works, so it certainly
could be a problem there.  PCI and USB passthrough are usually
documented as being "experimental" and/or "not guaranteed to work".
There are some extra features in fairly recent AMD CPUs that can help
with making passthrough work better.  The BIOSes on my AMD X570
motherboards have a couple of options that you can turn on, but the
kernel (and drivers?) also need to support those options for them to
work.  I expect that Intel CPUs will have the same or equivalent
features too.  But it might be too early yet for the VM software to be
supporting these new features.