Re: [PATCH] virt-aa-helper: allow common riscv64 loader paths

On Thu, Sep 29, 2022 at 11:30 PM Jim Fehlig wrote: > > On 9/28/22 06:45, christian.ehrha...@canonical.com wrote: > > From: Christian Ehrhardt > > > > Riscv64 usually uses u-boot as external -kernel and a loader from > > the open implementation of RISC-V SBI. The paths for those binaries > > as

questions regarding modular daemons

Hi All, I've procrastinated long enough and finally decided to switch to modular daemons in openSUSE Factory libvirt package. For the most part, the Factory spec file mimics the upstream one. I enabled with_modular_daemons and would like to confirm the results of my testing. When upgrading

Re: [PATCH] virt-aa-helper: allow common riscv64 loader paths

On 9/28/22 06:45, christian.ehrha...@canonical.com wrote: From: Christian Ehrhardt Riscv64 usually uses u-boot as external -kernel and a loader from the open implementation of RISC-V SBI. The paths for those binaries as packaged in Debian and Ubuntu are in paths which are usually forbidden to

[PATCH] docs: compiling: Add link to latest openSUSE libvirt package

This is a follow-up to fbd6b2480a, adding a link to the latest libvirt package for openSUSE. Signed-off-by: Jim Fehlig --- docs/compiling.rst | 4 1 file changed, 4 insertions(+) diff --git a/docs/compiling.rst b/docs/compiling.rst index bc43a929da..2a740ad76e 100644 ---

Re: [libvirt] [PATCH v2] qemu: Remove host-passthrough validation check for host-phys-bits=on

On 9/28/22 19:07, Jim Fehlig wrote: > On 9/8/22 01:07, Lin Ma wrote: >> Besides the -cpu host, The host-phys-bits=on applies to custom or max >> cpu model, So the host-passthrough validation check is unnecessary for >> maxphysaddr with mode='passthrough'. >> >> Signed-off-by: Lin Ma >> --- >>  

Re: [PATCH] virt-aa-helper: allow common riscv64 loader paths

On 9/28/22 14:45, christian.ehrha...@canonical.com wrote: > From: Christian Ehrhardt > > Riscv64 usually uses u-boot as external -kernel and a loader from > the open implementation of RISC-V SBI. The paths for those binaries > as packaged in Debian and Ubuntu are in paths which are usually >

Re: [PATCH v2] rpc: fix memory leak in virNetServerClientNew and virNetServerProgramDispatchCall

On 9/27/22 17:38, Jiang Jiacheng wrote: > From: jiangjiacheng > > In virNetServerProgramDispatchCall, The arg is passed as a void* and used to > point > to a certain struct depended on the dispatcher, so I think it's the memory of > the > struct's member that leaks and this memory shuld be

Re: [PATCH] qemuNamespaceMknodPaths: Don't fork needlessly

On a Thursday in 2022, Michal Privoznik wrote: The qemuNamespaceMknodPaths() function is responsible for creating files/directories in QEMU's mount namespace. When called, it is given list of paths that have to be created in the namespace. It processes this list and removes items that are not

Re: [PATCH] qemuProcessReconnect: Don't build memory paths

On a Thursday in 2022, Michal Privoznik wrote: Let me take you on a short trip to history. A long time ago, libvirt would configure all QEMUs to use $hugetlbfs/libvirt/qemu for their hugepages setup. This was problematic, because it did not allow enough separation between guests. Therefore in

Re: [PATCH] virdomainjob: preserveJob: memdup the cb structure instead of copying it

On 9/29/22 13:56, Kristina Hanicova wrote: > In case of variable 'oldjob' (job structure) in > qemuProcessReconnect() the init function was not called and the > cb pointer was just copied from the existing job structure in > virDomainObjPreserveJob(). This caused that the job and oldjob > had the

Re: [PATCH] virpcivpd: reduce errors in log due to invalid VPD

On 9/27/22 12:17, christian.ehrha...@canonical.com wrote: > From: Christian Ehrhardt > > Sadly some devices provide invalid VPD data even with fully updated > firmware. Former hardning like 600f580d "PCI VPD: Skip fields with > invalid values" have already helped for those to some extent. > But

[PATCH] virdomainjob: preserveJob: memdup the cb structure instead of copying it

In case of variable 'oldjob' (job structure) in qemuProcessReconnect() the init function was not called and the cb pointer was just copied from the existing job structure in virDomainObjPreserveJob(). This caused that the job and oldjob had the same pointer, which was later freed at the end of the

[PATCH] qemuProcessReconnect: Don't build memory paths

Let me take you on a short trip to history. A long time ago, libvirt would configure all QEMUs to use $hugetlbfs/libvirt/qemu for their hugepages setup. This was problematic, because it did not allow enough separation between guests. Therefore in v3.0.0-rc1~367 the path changed to a per-domain

[PATCH] qemuNamespaceMknodPaths: Don't fork needlessly

The qemuNamespaceMknodPaths() function is responsible for creating files/directories in QEMU's mount namespace. When called, it is given list of paths that have to be created in the namespace. It processes this list and removes items that are not directly under /dev, but on a 'shared' filesystem

Re: Why host device disappear in libvirt doman xml?

[I'm going to repeat this for the last time, please keep the list on CC list] On 9/29/22 10:15, 陈新隆 wrote: > Like pic below,  `cat /run/libvirt/qemu/.xml` outputs  alias='ua-gpu-gpu0' /> , `virsh dumpxml ` does not outputs gpu > hostdev. > It's usually better to paste the text, especially since

[PATCH] virgdbusmock: Mock g_dbus_connection_call_with_unix_fd_list_sync() only on UNIX-like systems

The g_dbus_connection_call_with_unix_fd_list_sync() function is not defined always, only when G_OS_UNIX condition is set. This is also the reason why our virGDBusCallMethodWithFD() function is guarded with that macro. But virgdbusmock is compiled always, even on !UNIX systems, e.g. mingw.