Pkg xen devel - Dec 2020 - [PATCH 7/9] debian/xen.init: Load xen_acpi_processor on boot

On Tue, Dec 15, 2020 at 12:18:15PM +0100, Hans van Kranenburg
wrote:
> I'm testing this change, but it seems I can't get past the
"modprobe:
> ERROR: could not insert 'xen_acpi_processor': No such device"
error on
> any hardware I have to test with. (with linux-image-5.9.0-4-amd64
> version 5.9.11-1 as dom0 kernel).
According to appropriate documentation, ENODEV comes from the module
itself and not the standard loading process.  In
linux-5.9/drivers/xen/xen-acpi-processor.c there are 3 occurrences of
ENODEV, so it would be one of those.  One of those has a pr_warn(), so it
would directly show up in `dmesg`.  The other two don't look as likely to
trigger and I'm unsure what messages they would produce.

My main Xen machine is presently on Xen 4.11 and kernel 4.19.  

Seems the comment above read_acpi_id() has been broken.  :-(  Right now
if Dom0 has fewer vCPUs than the machine has actual processors, the
C-states don't get setup for the processors which lack vCPUs.  Workaround
I've got right now is hot unplugging some processors after boot.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

On 12/15/20 5:43 PM, Elliott Mitchell wrote:
> On Tue, Dec 15, 2020 at 12:18:15PM +0100, Hans van Kranenburg wrote:
>> I'm testing this change, but it seems I can't get past the
"modprobe:
>> ERROR: could not insert 'xen_acpi_processor': No such
device" error on
>> any hardware I have to test with. (with linux-image-5.9.0-4-amd64
>> version 5.9.11-1 as dom0 kernel).
> 
> According to appropriate documentation, ENODEV comes from the module
> itself and not the standard loading process.  In
> linux-5.9/drivers/xen/xen-acpi-processor.c there are 3 occurrences of
> ENODEV, so it would be one of those.  One of those has a pr_warn(), so it
> would directly show up in `dmesg`.  The other two don't look as likely
to
> trigger and I'm unsure what messages they would produce.
Also looking at the code now.

There is nothing in dmesg, so it's probably not the first -ENODEV.

There was a conversation about it on IRC. Others can modprobe it without
the error. Someone suggested that if you have another thing in place
that is already involved in power management, it might refuse to load.
Now, the case here is that the machines I test with are different
generations of HP Proliant dl360 and we always configure them for
'static high power and performance', disabling any form of cpu frequency
scaling. Maybe that's the reason that something is not available that
the module would expect to be able to use. Just guessing.

I'm not going to examine all the ACPI info tonight to find out.
> My main Xen machine is presently on Xen 4.11 and kernel 4.19.  
> 
> Seems the comment above read_acpi_id() has been broken.  :-(  Right now
> if Dom0 has fewer vCPUs than the machine has actual processors, the
> C-states don't get setup for the processors which lack vCPUs. 
Workaround
> I've got right now is hot unplugging some processors after boot.
Oh, interesting.

Anyway, since it works for others, it's certainly good that we try to
load it now. :) Apparently things can be improved even more, but at
least it's already better than nothing.

Hans