[Cin] libaom 3.2.0 patch1 fixed for arm/linux?

[Andrew Randrianasulu]

On Tuesday, January 11, 2022, Andrew Randrianasulu <randrianasulu at gmail.com>
wrote:

>
>
> On Tuesday, January 11, 2022, <mnieuw at zap.a2000.nl> wrote:
>
>> On Tue, 11 Jan 2022 18:46:59 +0300
>> Andrew Randrianasulu <randrianasulu at gmail.com> wrote:
>>
>> <snip>
>> > > > I think you already using system mode (full system emulation - so
>> > > > you can run NetBsd or MacOS or windows - they see emulated/virtual
>> > > > machine to run on..) User-mode qemu run Linux binaries on top of
>> > > > same kernel BUT they can belong to another architecture! So
>> > > > overhead can be less.. (no mmu emulation). You can edit files
>> > > > inside proot 'vm' from host - no need for samba/nfs.
>> > >
>> > > I have macOS in user mode, it runs fine (but need to re-install). It
>> > > also ran fine in system mode (since deleted). I have not checked if
>> > > there is a speed difference between the two nodes, nothing very
>> > > noticable anyway.
>> >
>> >
>> > I think your terminology on system/user modes a bit different from
>> > assumed by qemu?
>> >
>> > Can you try to explain what you mean by those two modes in your own
>> > words/experience?
>>
>> In virt-manager you can have two kinds of VMs: QEMU/KVM and QEMU/KVM
>> User Session. The first is referred to as "system", the second as
>> "session". The default on Fedora_35 is (user) session, where qemu runs
>> under the user's profile. If you use virsh to e.g.
>> edit the VM's config you can type e.g. "virsh edit Debian11_aarch64" .
>> If you want to use a VM under system, you have to type "virsh --connect
>> qemu:///system edit Debian11_aarch64".
>> The VMs have a different domain specified in the XML that defines a VM.
>> user mode has domain "qemu", system mode domain "kvm".
>> I noticed that whereas in user (session) mode you can define pretty
>> much any hardware for the VM, in system mode some things are not
>> available, like PCIe controllers.
>
>


https://wiki.libvirt.org/page/FAQ#What_is_the_difference_between_qemu:.2F.2F.2Fsystem_and_qemu:.2F.2F.2Fsession.3F_Which_one_should_I_use.3F

====
What is the difference between qemu:///system and qemu:///session? Which
one should I use?
All 'system' URIs (be it qemu, lxc, uml, ...) connect to the libvirtd
daemon running as root which is launched at system startup. Virtual
machines created and run using 'system' are usually launched as root,
unless configured otherwise (for example in /etc/libvirt/qemu.conf).

All 'session' URIs launch a libvirtd instance as your local user, and all
VMs are run with local user permissions.

You will definitely want to use qemu:///system if your VMs are acting as
servers. VM autostart on host boot only works for 'system', and the root
libvirtd instance has necessary permissions to use proper networkings via
bridges or virtual networks. qemu:///system is generally what tools like
virt-manager default to.

qemu:///session has a serious drawback: since the libvirtd instance does
not have sufficient privileges, the only out of the box network option is
qemu's usermode networking, which has nonobvious limitations, so its usage
is discouraged. More info on qemu networking options:
http://people.gnome.org/~markmc/qemu-networking.html

The benefit of qemu:///session is that permission issues vanish: disk
images can easily be stored in $HOME, serial PTYs are owned by the user,
etc.

====

well... this is something virt-manager specific as I guessed..  all qemu
modes likely run qemu-system-* under the hood (but uml is user-mode linux
and lxc is container... mode. non-system, as far as guest kernel not needed
for them... if I recall things correctly!). you can check with top while vm
is running...

>
> ah, thanks... so, this is virt-manager specific terminology..
>
> I was referring to other method of qemu use, one where you call
> qemu-user-something and not qemu-system-something.
>
>>
>> MatN
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220111/7d2b6a2e/attachment-0001.htm>