-host-validate to check of /dev/cpu/*/msr is
available.
Signed-off-by: Hector Cao
---
meson_options.txt| 1 +
src/util/meson.build | 19 +++
src/util/modules-load.d/msr.conf | 1 +
tools/virt-host-validate-qemu.c | 7 +++
4 files changed, 28 inser
when qemu driver is enabled
Hector Cao (1):
x86: install modules-load.d file to load msr module
meson_options.txt| 1 +
src/util/meson.build | 19 +++
src/util/modules-load.d/msr.conf | 1 +
tools/virt-host-validate-qemu.c | 7 +++
4 files
On Thu, Sep 4, 2025 at 11:40 PM Jim Fehlig wrote:
> On 9/3/25 06:49, Hector Cao wrote:
> > On recent Intel CPUs, some of the CPU features (mostly
> > vmx-* subfeatures) are listed and controlled via the
> > MSRs (Model Specific Registers) instead of the traditional
> &g
On Fri, Sep 5, 2025 at 1:48 AM Jim Fehlig wrote:
> On 9/4/25 17:00, Hector Cao wrote:
> >
> >
> > On Thu, Sep 4, 2025 at 11:40 PM Jim Fehlig > <mailto:jfeh...@suse.com>> wrote:
> >
> > On 9/3/25 06:49, Hector Cao wrote:
> > >
te to check of /dev/cpu/*/msr is
available.
Signed-off-by: Hector Cao
---
meson_options.txt| 1 +
src/util/meson.build | 17 +
src/util/modules-load.d/msr.conf | 1 +
tools/virt-host-validate-qemu.c | 7 +++
4 files changed, 26 insertions(+)
c
libvirt deploy the modules-load.d configuration
so that linux loads the msr module at next boot.
One caveat, libvirt installs only the file and does not trigger the load that
is only done at next reboot, it is up to each distro to trigger immediately
the load of the module without a reboot.
Hector Cao
is useful both for users to align their expectation and for
us to point to a place where the situation is clearly explained.
Signed-off-by: Hector Cao
---
docs/formatcaps.rst | 44
1 file changed, 44 insertions(+)
diff --git a/docs/formatcaps.rst b
On Wed, Aug 27, 2025 at 4:19 PM Jiri Denemark wrote:
> On Wed, Aug 27, 2025 at 14:24:13 +0200, Hector Cao wrote:
> > Hello,
> >
> > This is a follow-up of the submission:
> >
> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/EZBLO5CIGC3FTI5J7
ction will be rendered at : https://libvirt.org/formatcaps.html
Best regards,
Hector
v3:
- modifications based on Jiri's feedback on the v2
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/PRXVIQKK66M7AQGX5OCC4FGJ2PRLA6UU/
v2:
- wrap lines at 80 characters
Hello Michal,
Thanks for the feedback !
Here is the v2 where I took into consideration your valuable feedback.
Please take a look !
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/J5IC2LB2LZBWXGOKIO33UG7IU7SGXBG3/
Best,
Hector
From: Hector Cao
when a device is dynamically attached to a VM, and it needs a special
system access for apparmor, libvirt calls virt-aa-helper (with argument -F)
to append a new rule to the apparmor profile of the VM. virt-aa-helper does
not check for duplicate and blindly appends the rule to
Michal Prívozník for the original
submission:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/2HIZC2EK72NBLMCNGT54XIVGJEGG7YNN/
v2:
- early exit if duplicate is detected
- improve the check condition for existing profile data
Hector Cao (1):
virt-aa-helper: Avoid duplicate
From: Hector Cao
when a device is dynamically attached to a VM, and it needs a special
system access for apparmor, libvirt calls virt-aa-helper (with argument -F)
to append a new rule to the apparmor profile of the VM. virt-aa-helper does
not check for duplicate and blindly appends the rule to
Hello Jirka,
Do you have time to think about this ?
If you are ok, I can go ahead and propose a solution to this issue,
Best regards,
Hector
Bolognani
wrote:
> On Fri, Jul 25, 2025 at 01:25:47PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Jul 25, 2025 at 01:45:51PM +0200, Hector Cao wrote:
> > > One thing I'm worried about with modules-load.d approach is that at
> libvirt
> > > installation, the mod
PI process to start a guest.
>
>
One thing I'm worried about with modules-load.d approach is that at libvirt
installation, the module
is not actually loaded, a reboot is necessary to make it happen.
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o-
> http
On Fri, Jul 25, 2025 at 11:22 AM Daniel P. Berrangé
wrote:
> On Wed, Jul 23, 2025 at 08:15:25PM +0200, Hector Cao wrote:
> > On Wed, Jul 9, 2025 at 12:01 PM Daniel P. Berrangé
> > wrote:
> >
> > > On Wed, Jul 09, 2025 at 05:58:03AM -0400, Andrea Bolognani wrote:
&
On Wed, Jul 9, 2025 at 12:01 PM Daniel P. Berrangé
wrote:
> On Wed, Jul 09, 2025 at 05:58:03AM -0400, Andrea Bolognani wrote:
> > On Wed, Jul 09, 2025 at 09:53:40AM +0100, Daniel P. Berrangé via Devel
> wrote:
> > > On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote:
Hello Jiri,
Did you have any chance to take a look at this ?
I would like to know your thoughts on it
Thanks
Hector
From: Hector Cao
Add documentation on the way libvirt displays the Host CPU
model and capabilities (features). There is an implicit
expection from users to get the CPU model name matching the
CPU model they are running on, however, this does not happen
most of the time. As a consequence, having
ction will be rendered at : https://libvirt.org/formatcaps.html
Best regards,
Hector
v2:
- wrap lines at 80 characters
Hector Cao (1):
docs : add doc on cpu model and features
docs/formatcaps.rst | 43 +++
1 file changed, 43 insertions(+)
--
2.34.1
Thanks Daniel,
On Wed, Jul 9, 2025 at 10:17 AM Daniel P. Berrangé
wrote:
> On Wed, Jul 09, 2025 at 10:03:26AM +0200, Hector Cao wrote:
> > Hello,
> >
> > This mail is a Request for Comment.
> >
> > On recent Intel CPUs, some of the CPU features (mostly vmx-
Hello,
This mail is a Request for Comment.
On recent Intel CPUs, some of the CPU features (mostly vmx-* subfeatures)
are listed and controlled
via the MSRs (Model Specific Registers) instead of the traditional CPUID
instruction method.
Right now, libvirt reads the MSR's values via /dev/cpu/*/cpu
From: Hector Cao
Add documentation on the way libvirt displays the Host CPU
model and capabilities (features). There is an implicit
expection from users to get the CPU model name matching the
CPU model they are running on, however, this does not happen
most of the time. As a consequence, having
From: Hector Cao
Hello,
This is a follow-up of the submission:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/EZBLO5CIGC3FTI5J72WNVAKWPSNQFLCY/
Based on Jiri's feedback, it is better to tackle this situation by
documentation. You can find here a proposal fo
On Mon, Jun 16, 2025 at 2:39 PM Jiří Denemark wrote:
> On Mon, Jun 16, 2025 at 02:14:15 +0200, Hector Cao wrote:
> > On Mon, Jun 2, 2025 at 3:23 PM Jiří Denemark
> wrote:
> > > So except for not having the right CPU model in the capabilities XML
> > > (which is
On Mon, Jun 2, 2025 at 3:23 PM Jiří Denemark wrote:
> On Mon, Jun 02, 2025 at 14:30:43 +0200, Hector Cao wrote:
> > Hello Jiri,
> >
> > Thanks for the feedback,
> >
> > On Mon, Jun 2, 2025 at 9:30 AM Jiri Denemark
> wrote:
> >
> > > On Mo
amp;item);
}
}
On Sun, Jun 1, 2025 at 11:01 PM Hector Cao wrote:
> I just realized that I should not modify the x86_features.xml file
> directly.
>
> I have to fix this issue elsewhere, probably in
> the sync_qemu_features_i386.py
> script or in the libvirt code tha
Hello Jiri,
Thanks for the feedback,
On Mon, Jun 2, 2025 at 9:30 AM Jiri Denemark wrote:
> On Mon, Jun 02, 2025 at 01:19:29 +0200, Hector Cao wrote:
> > Several Intel CPU models with TSX technology (HLE & RTM features) are
> > affected by the vulnerability TAA[1]. One of the
Several Intel CPU models with TSX technology (HLE & RTM features) are
affected by the vulnerability TAA[1]. One of the mitigation methods
for TAA is to disable TSX support on the host system. For that purpose,
in 2021, Intel published a microcode update to disable TSX. Linux kernel
also disables TS
(IA32_VMX_PROCBASED_CTLS2)
but has the login to interpret this bit position correctly in the register
raw value.
Libvirt does not have this login and by consequence, does not get the right
bit value.
I would appreciate some feedback on how we can best tackle this.
On Sat, May 31, 2025 at 12:31 AM Hector Cao
& 3D): System Programming Guide
Signed-off-by: Hector Cao
---
src/cpu_map/x86_features.xml | 136 +--
1 file changed, 68 insertions(+), 68 deletions(-)
diff --git a/src/cpu_map/x86_features.xml b/src/cpu_map/x86_features.xml
index d06d60e230..0f60adb388 10
ectly detected.
Hector Cao (1):
cpu_map: fix vmx-* features wrong bitmaps
src/cpu_map/x86_features.xml | 136 +--
1 file changed, 68 insertions(+), 68 deletions(-)
--
2.45.2
etail, reports "REBOOTED" as the cause. That would let
> control plane software understand that these events are from a fake
> reboot.
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvir
Hello Zhenzhong and Daniel,
With this implementation, upon TD reboot, some events
VIR_DOMAIN_EVENT_ID_LIFECYCLE are emitted (STARTED, STOPPED and probably
SHUTDOWN and RESUMED).
For normal VM, only the event VIR_DOMAIN_EVENT_ID_REBOOT is emitted.
Do you think it is good to align the API for TD
35 matches
Mail list logo
