On 03/07/2018 05:51 PM, Boris Ostrovsky wrote:
> On 03/06/2018 03:12 PM, Joao Martins wrote:
>> All uploaded PM data from offline CPUs takes the info from vCPU 0 and
>
> "offline" may not be the right term here. Maybe "non-dom0"?
>
Yeah, probably clearer to use that.
>> changing only the
On 03/07/2018 05:51 PM, Boris Ostrovsky wrote:
> On 03/06/2018 03:12 PM, Joao Martins wrote:
>> All uploaded PM data from offline CPUs takes the info from vCPU 0 and
>
> "offline" may not be the right term here. Maybe "non-dom0"?
>
Yeah, probably clearer to use that.
>> changing only the
On 03/06/2018 03:12 PM, Joao Martins wrote:
> All uploaded PM data from offline CPUs takes the info from vCPU 0 and
"offline" may not be the right term here. Maybe "non-dom0"?
> changing only the acpi_id. For processors which P-state coordination type
> is HW_ALL (0xFD) it is OK to upload bogus
On 03/06/2018 03:12 PM, Joao Martins wrote:
> All uploaded PM data from offline CPUs takes the info from vCPU 0 and
"offline" may not be the right term here. Maybe "non-dom0"?
> changing only the acpi_id. For processors which P-state coordination type
> is HW_ALL (0xFD) it is OK to upload bogus
All uploaded PM data from offline CPUs takes the info from vCPU 0 and
changing only the acpi_id. For processors which P-state coordination type
is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information
(_PSD), because Xen will ignore cpufreq domains existence.
Albeit for hardware
All uploaded PM data from offline CPUs takes the info from vCPU 0 and
changing only the acpi_id. For processors which P-state coordination type
is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information
(_PSD), because Xen will ignore cpufreq domains existence.
Albeit for hardware
6 matches
Mail list logo
