Re: Help in porting smack related patches to meson build system
by Peter Krempa
On Mon, Sep 19, 2022 at 16:31:25 +0000, Vishal Gupta (vishagu2) wrote:
> Hi Peter ,
Hi,
I firstly want to ask you to avoid top-posting on technical mailing
lists.
>
>
>
> Thanks for ur reply .
>
>
>
> Kirkstone is the latest release from Yocto foundation . details https://docs.yoctoproject.org/dev/migration-guides/migration-4.0.html
>
>
>
> Kirkstone support libvirt 8.10 https://layers.openembedded.org/layerindex/recipe/3052/
>
>
>
> We are trying to port 2016 smack patch " https://listman.redhat.com/archives/libvir-list/2016-July/msg00456.html" for libvirt which is based on automake make file
Okay so that is quite an old patch which was never finished and merged.
> But above patch is incompatible with libvirt 8.10 .as libvirt 8.1 supports only meson
>
>
> I was just wondering if above smack patch is already ported for meson based libvirt 8.10?
>
> We have issue in porting m4/virt-smack.m4 to meson.build file . virt-smack.m4 is define in 2016 smack patch
No it is not ported. I want to warn you though that porting the build
system part to meson will not be biggest of the problems.
1) The patch is more than 6 years old at this point
There's quite a lot of change in libvirt during that time. Many
helpers and internal APIs were refactored. The patch even once you
port the build system will require *significant* rework to actually
even compile.
2) libsmack (smack-utils) used by the new security module is not present
in distros
The library it requires doesn't seem to be adopted much:
https://repology.org/project/smack-utils/versions
Did you make sure that it's present in your environment?
Additionally if you want to get the patch accepted upstream note that
there were outstanding problems with the patch in the last version
which is on the mailing list. I can see that there are definitely
problems with coding style and the patch will need to be split to
logical chunks as it's now just a big blob of code.
Also given that the library is simply not present in distros it will
require a justification why upstream should cary the patch. Carying
code which is not compiled because of lack of dependencies is a burden
to upstream and still can bitrot in the future.
Even if you are not striving for upstreaming the patch, be prepared for
more work than just porting the build system.
2 years, 1 month
Help in porting smack related patches to meson build system
by Akash Bhaskaran (akabhask)
Hi,
We are trying to port some patches pertaining to files like Makefile.am ,configure.ac and .m4’s to libvirt kirkstone release. We see that latest kirskstone now uses meson build architecture. We have difficulties in porting the changes in the above-mentioned files to meson. Is there any script or reference you can provide for helping us port these files to meson?
Thanks,
Akash
2 years, 1 month
virt-manager alt-click passthrough?
by Alex
Hi, I'm using virt-manager to connect to a Windows 10 virtual machine,
where I'm using photoshop.
I need to send an alt-click key for some functions, but virt-manager is
instead interpreting them. It isn't among the pre-configured options that
can be sent. Is there a way to remap the alt key or alt-click combination
so I can send it through to the virtual machine?
I've also tried the RealVNC client/server trial, and I can't get that to
connect at all. It does appear qemu/realvnc server is listening on 5900:
tcp 0 0 127.0.0.1:5900 0.0.0.0:* LISTEN
-
qemu is also configured to listen (-spice port=5900,addr=127.0.0.1). I've
also verified I can connect to port 5900 manually, so a Windows firewall is
not the problem.
Any ideas greatly appreciated.
2 years, 1 month
[libvirt-users] [virtual interface] detach interface during boot succeed with no changes
by Yalan Zhang
Hi guys,
when I detach an interface from vm during boot (vm boot not finished), it
always fail. I'm not sure if there is an existing bug. I have
confirmed with someone that for disk, there is similar behavior, if
this is also acceptable?
# virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 2; virsh
detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh
dumpxml rhel7.2 |grep /interface -B9
Domain rhel7.2 destroyed
Domain rhel7.2 started
Interface detached successfully
<address type='pci' domain='0x0000' bus='0x00' slot='0x06'
function='0x0'/>
</controller>
<interface type='network'>
<mac address='52:54:00:98:c4:a0'/>
<source network='default' bridge='virbr0'/>
<target dev='vnet0'/>
<model type='rtl8139'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
</interface>
When I detach after the vm boot, expand the sleep time to 10, it will succeed.
# virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 10; virsh
detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh
dumpxml rhel7.2 |grep /interface -B9
Domain rhel7.2 destroyed
Domain rhel7.2 started
Interface detached successfully
-------
Best Regards,
Yalan Zhang
IRC: yalzhang
Internal phone: 8389413
2 years, 1 month
CPU features/flags - host vs. guest (Libvirt/QEMU/KVM)
by kAja Ziegler
Hello,
does anyone know of any list/table (ideally as up-to-date as possible)
with individual CPU features/flags for x86_64 (preferably Intel), which
would state:
- description of individual features/flags
- dependencies between individual features/flags - e.g. avx on xsave
- what features/flags are checked on the hypervisor (host), but are not
propagated to the guest - e.g. acpi, ds, monitor, pbe, tm, etc. - some are
masked/disabled [(not) supported] by Libvirt, others by KVM/QEMU
- what features/flags active for/in the guest limit certain virtualization
behavior/options such as live migration - e.g. invtsc, xsaves
- so far I only found
https://github.com/libvirt/libvirt/blob/master/src/cpu_map/x86_features.xml
- features with migratable='no'
I would like to tweak the CPU configuration for the virtual servers ie.
choose the basic CPU model and turn on/off the necessary or appropriate
features/flags while maintaining the possibility of live migration. But I
miss the above-mentioned contexts, because not all the mentioned features
within the cpu element in the VM definition (domains in Libvirt) are then
visible inside the VM in /proc/cpuinfo. Of course, I know about other
related commands, registers, etc. like "virsh
capabilities|cpu-baseline|cpu-compare", MSR, fixes in CPU microcode,
host-model or host-passthrough CPU... but I'm still not sure about setting
the match, check and fallback attributes and the resulting behavior of
Libvirt and QEMU/KVM.
Many thanks in advance for any response
K. Ziegler
2 years, 1 month
