[PATCH V2 0/7] add ACRN CPU performance management


Zhou, Wu
 

1. Background:

Customers of the industry segment are asking for more computation power
in WaaG. Currently there are two ways to manage CPU frequency when
running ACRN:
- Pass through p-state to guest. This doesn't work because windows
frequency driver is not loaded in guest mode.
- Let service VM's Linux cpufreq driver to manage CPU frequency. But
service VM is not aware of guests' work load, so the CPU frequency
can't be boosted rightly.

So we have to let ACRN manage CPU frequency.

2. The design:

The design of ACRN CPU performance management is to let hardware do the
autonomous frequency selection(or set to a fixed value), and remove all
guests' capability to control CPU frequency.

If the platform supports HWP, we can use HWP to do the hardware autonomous
selection. The hypervisor just need to setup HWP_REQUEST at start up,
and no need to be governing the frequency after this. But for ACPI
p-state, the CPU frequency can only be fixed.

Cores running RTVMs are always fixed to nominal/guaranteed frequency, to
get more certainty in latency.

Users may have preference on how the CPU frequency is managed. So we
provide two performance policy types for users to choose from:
- 'Performance': CPU runs at its CPU runs at its maximum
frequency. Enable hardware autonomous frequency selection if HWP is
presented.
- 'Nominal': CPU runs at its guaranteed frequency.
(*Note: The performance 'policy' was called 'governor' in the first
edition of this patch series. But ACRN don't actually 'govern' the
frequency. It just apply the policy at start up. So the word 'policy'
might be more appropriate.)

The policy type is passed to hypervisor through boot parameter, as
either 'cpu_perf_policy=Nominal' or 'cpu_perf_policy=Performance'.
The default type is 'Performance'.

An configurate item is provided to user to choose the policy.
Config-tool will then generate the boot parameter automatically.
But it can always be changed by editting the grub cfg.

3. The implementation:
- Add a config item and automatically generate policy parameter.
(1/7, 2/7)
- Extract CPU frequency info and generate frequency limits from
config-tools. This could save hypervisor code. (3/7, 4/7)
- Implement CPU frequency initializer. (5/7)
- remove guest's ability to control CPU frequency by removing the guests'
HWP/EIST CPUIDs and blocking the related MSR accesses. (6/7)
- Do not generate ACPI p-state tables for post launched VMs in DM.
(7/7)


Change made in V2:

1. Renamed 'governor' to 'policy'.
2. Pass policy to ACRN through boot parameter.
3. HWP/p-state now is auto selected in hv.
4. Removed p-state pass through.
5. Rewrite all the commit messages and cover letter.
6. Move the blocked MSRs to 'unsupported_msrs'.

--
2.25.1


Eddie Dong
 

-----Original Message-----
From: acrn-dev@... <acrn-dev@...> On
Behalf Of Zhou, Wu
Sent: Friday, September 2, 2022 7:52 AM
To: acrn-dev@...
Cc: Zhou, Wu <wu.zhou@...>
Subject: [acrn-dev] [PATCH V2 0/7] add ACRN CPU performance management

1. Background:

Customers of the industry segment are asking for more computation power in
WaaG. Currently there are two ways to manage CPU frequency when running
ACRN:
- Pass through p-state to guest. This doesn't work because windows
frequency driver is not loaded in guest mode.
This is still not clear. I remember what the meeting said was: The Windows OS running in a VM (initially designed for Hyper-V) relies on Hyper-V to manage the frequency, so it doesn't have frequency driver.

This way, we want to do something similar as Hyper-V does.

- Let service VM's Linux cpufreq driver to manage CPU frequency. But
service VM is not aware of guests' work load, so the CPU frequency
can't be boosted rightly.
This is not clear either. HWP let HW manages the frequency. It doesn't rely on service VM to manage.

What I can say is probably we don't want service VM to change the frequency of RTVM, given that RTVM may have higher severity.
Or any other reason?

So we have to let ACRN manage CPU frequency.

2. The design:

The design of ACRN CPU performance management is to let hardware do the
autonomous frequency selection(or set to a fixed value), and remove all
guests' capability to control CPU frequency.

If the platform supports HWP, we can use HWP to do the hardware
autonomous selection. The hypervisor just need to setup HWP_REQUEST at
start up, and no need to be governing the frequency after this. But for ACPI p-
state, the CPU frequency can only be fixed.

Cores running RTVMs are always fixed to nominal/guaranteed frequency, to
get more certainty in latency.

Users may have preference on how the CPU frequency is managed. So we
provide two performance policy types for users to choose from:
- 'Performance': CPU runs at its CPU runs at its maximum
frequency. Enable hardware autonomous frequency selection if HWP is
presented.
- 'Nominal': CPU runs at its guaranteed frequency.
(*Note: The performance 'policy' was called 'governor' in the first edition of
this patch series. But ACRN don't actually 'govern' the frequency. It just apply
the policy at start up. So the word 'policy'
might be more appropriate.)

The policy type is passed to hypervisor through boot parameter, as either
'cpu_perf_policy=Nominal' or 'cpu_perf_policy=Performance'.
The default type is 'Performance'.

An configurate item is provided to user to choose the policy.
Config-tool will then generate the boot parameter automatically.
But it can always be changed by editting the grub cfg.

3. The implementation:
- Add a config item and automatically generate policy parameter.
(1/7, 2/7)
- Extract CPU frequency info and generate frequency limits from
config-tools. This could save hypervisor code. (3/7, 4/7)
- Implement CPU frequency initializer. (5/7)
- remove guest's ability to control CPU frequency by removing the guests'
HWP/EIST CPUIDs and blocking the related MSR accesses. (6/7)
- Do not generate ACPI p-state tables for post launched VMs in DM.
(7/7)


Change made in V2:

1. Renamed 'governor' to 'policy'.
2. Pass policy to ACRN through boot parameter.
3. HWP/p-state now is auto selected in hv.
4. Removed p-state pass through.
5. Rewrite all the commit messages and cover letter.
6. Move the blocked MSRs to 'unsupported_msrs'.

--
2.25.1