A very small correction to Marek's summary, only matters if you really
going to look at details:
Marek Marczykowski-Górecki:
[...]
> 2. When toolstack issues "suspend" command (via xenstore
> control/shutdown), Linux uses "freeze" path, that doesn't put devices
> into low power state. Changing tha
Roger Pau Monné:
> On Mon, Sep 11, 2023 at 12:12:38PM +0200, Simon Gaiser wrote:
>> Up to version 6.2 Errata B [2] the ACPI spec only defines
>> ACPI_MADT_ENABLE as:
>>
>> If zero, this processor is unusable, and the operating system
>> support will not
l.org/xen-devel/0bd3583c-a55d-9a68-55b1-c383499d4...@suse.com/
# [1]
Link:
https://lore.kernel.org/xen-devel/f780d40e-c828-c57a-b19c-16ee15c14...@suse.com/
# [2]
Signed-off-by: Simon Gaiser
---
xen/arch/x86/acpi/boot.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
d
Jan Beulich:
> On 07.08.2023 11:38, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>> 0xff. Linux already has code to handle those cases both in
>> a
Jan Beulich:
> On 11.09.2023 12:12, Simon Gaiser wrote:
>> Up to version 6.2 Errata B [2] the ACPI spec only defines
>> ACPI_MADT_ENABLE as:
>>
>> If zero, this processor is unusable, and the operating system
>> support will not attempt to use it.
Andrew Cooper:
> On 07/08/2023 3:45 pm, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>>> existing processors. On my NUC11TNHi5 those
nk: https://uefi.org/sites/default/files/resources/ACPI_6_3_May16.pdf # [3]
Link:
https://git.kernel.org/torvalds/c/e2869bd7af608c343988429ceb1c2fe99644a01f # [4]
Link:
https://lore.kernel.org/xen-devel/80bae614-052e-0f90-cf13-0e5e4ed1a...@invisiblethingslab.com/
# [5]
Signed-off-by: Simon Gaiser
---
Jan Beulich:
> On 07.08.2023 14:55, Simon Gaiser wrote:
>> Jan Beulich:
>>> On 07.08.2023 11:38, Simon Gaiser wrote:
>>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>>> existing processors. On my NUC11TNHi5 those have the in
Andrew Cooper:
> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>> 0xff. Linux already has code to handle those cases both in
>&
Jan Beulich:
> On 07.08.2023 11:38, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>> 0xff. Linux already has code to handle those cases both in
>> a
Jan Beulich:
> On 07.08.2023 11:58, Simon Gaiser wrote:
>> Jan Beulich:
>>> On 07.08.2023 10:18, Simon Gaiser wrote:
>>>> Anthony Liguori:
>>>>> From: Jan H. Schönherr
>>>>>
>>>>> Intel says for CPUID leaf
com/
# [2]
Signed-off-by: Simon Gaiser
---
[ Resending v3, now with a unique Message-ID, sorry. ]
Changes in v3:
- Edit log message and downgrade it to XENLOG_DEBUG.
Changes in v2:
- Always disable legacy mode after test, not only when ARAT is
available. See [3] for reasoning.
[3]:
ht
Andrew Cooper:
> On 07/08/2023 11:01 am, Andrew Cooper wrote:
>> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>
Jan Beulich:
> On 07.08.2023 10:18, Simon Gaiser wrote:
>> Anthony Liguori:
>>> From: Jan H. Schönherr
>>>
>>> Intel says for CPUID leaf 0Bh:
>>>
>>> "Software must not use EBX[15:0] to enumerate processor
>>>topolog
Jan Beulich:
> On 31.07.2023 12:32, Simon Gaiser wrote:
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -1967,6 +1967,8 @@ static void __init check_timer(void)
>>
>> if ( timer_irq_works() )
>> {
>>
a9bf4
# [2]
Signed-off-by: Simon Gaiser
---
xen/arch/x86/acpi/boot.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c
index 54b72d716b..4a62822fa9 100644
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.
Anthony Liguori:
> From: Jan H. Schönherr
>
> Intel says for CPUID leaf 0Bh:
>
> "Software must not use EBX[15:0] to enumerate processor
>topology of the system. This value in this field
>(EBX[15:0]) is only intended for display/diagnostic
>purposes. The actual number of logical pr
com/
# [2]
Signed-off-by: Simon Gaiser
---
Changes in v2:
- Always disable legacy mode after test, not only when ARAT is
available. See [3] for reasoning.
[3]:
https://lore.kernel.org/xen-devel/ac77ecba-6804-1d16-60dc-f184e5d31...@invisiblethingslab.com/
---
xen/arch/x86/io_apic.c | 2 ++
Simon Gaiser:
> This allows entering and exiting s2idle. Actual S0ix residency is
> another topic [1].
>
> Without this the ACPI code currently ignores the error enable_irq_wake()
> returns when being used on a xen-pirq and the system goes to idle for
> ever since the wakeu
Jan Beulich:
> On 18.07.2023 23:51, Simon Gaiser wrote:
>> Roger Pau Monné:
>>> On Tue, Jul 18, 2023 at 02:26:03PM +0200, Simon Gaiser wrote:
>>>> As far as I understand the HPET legacy mode is not required on systems
>>>> with ARAT after the timer IRQ t
Andrew Cooper:
> On 18/07/2023 2:17 pm, Simon Gaiser wrote:
>> Since it's limited to the hardware domain it should be safe and it's
>> very useful to have access to this directly in dom0 when debugging power
>> related things for example S0ix.
>
> You need a
Jan Beulich:
> On 18.07.2023 15:17, Simon Gaiser wrote:
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -965,6 +965,20 @@ static int cf_check read_msr(
>> *val = 0;
>> return X86EMUL_OKAY;
>>
>>
Roger Pau Monné:
> On Tue, Jul 18, 2023 at 02:26:03PM +0200, Simon Gaiser wrote:
>> As far as I understand the HPET legacy mode is not required on systems
>> with ARAT after the timer IRQ test.
>
> What's the relation with ARAT here?
>
> It would seem to me
Jan Beulich:
> On 18.07.2023 15:46, Simon Gaiser wrote:
>> Jan Beulich:
>>> On 18.07.2023 15:23, Simon Gaiser wrote:
>>>> ---
>>>> xen/arch/x86/acpi/cpu_idle.c | 9 ++---
>>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
&g
Jan Beulich:
> On 18.07.2023 15:23, Simon Gaiser wrote:
>> ---
>> xen/arch/x86/acpi/cpu_idle.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> This lacks both S-o-b and a proper description. The latter in
> particular because you ...
Yeah,
Please excuse the wrong subject prefix. It should have been [XEN PATCH].
This is a single patch.
Simon
OpenPGP_signature
Description: OpenPGP digital signature
---
xen/arch/x86/acpi/cpu_idle.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 557bc6ef86..a6d3175156 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -155,6 +155,12 @@ s
Since it's limited to the hardware domain it should be safe and it's
very useful to have access to this directly in dom0 when debugging power
related things for example S0ix.
---
xen/arch/x86/include/asm/msr-index.h | 9 +
xen/arch/x86/pv/emul-priv-op.c | 14 ++
2 files
/
# [1]
Signed-off-by: Simon Gaiser
---
xen/arch/x86/io_apic.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index 9b8a972cf5..ea98d717d0 100644
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1966,6 +1966,10 @@ static void
I. This is not implemented here, for CPUs with
internal config nothing is changed.
Signed-off-by: Simon Gaiser
---
Sending this as RFC to get feedback on implementing it this way. I tried
to keep this change small and to avoid changing the existing code path
for CPUs with a config included in the
Andrew Cooper:
[...]
>> It reaches low power states only for a fraction of the suspend to idle
>> time, so something still makes the CPU/chipset think it should leave the
>> low power mode, but that's another topic.
>
> Do you have any further info here? There are a range of possibilities,
> from
Roger Pau Monné:
> On Mon, Feb 27, 2023 at 12:48:03PM +0100, Simon Gaiser wrote:
>> Hi,
>>
>> I have been looking into using S0ix with Xen. On systems with with
>> 11th gen (Tiger Lake) Intel mobile CPUs or newer this is often the
>> only supported suspend meth
Hi,
I have been recently looking into getting S0ix working on Xen [1].
Thanks to a tip from Andrew I found that the HPET legacy mode was
preventing my test system from reaching a package C-state lower than PC7
and thereby also preventing S0ix residency.
For testing I simply modified check_timer(
Simon Gaiser:
[...]
> On my test system (NUC11TNHi5, Tiger Lake) I haven't seen it reaching
> cstates lower PC7 with Xen (so it can of course not reach S0ix
> residency). With plain Linux I got it working on that system although it
> was rather fiddly and probably somethin
or is
handled and the system refuses to go to s2idle.
Link:
https://lore.kernel.org/xen-devel/9051e484-b128-715a-9253-48af8e47b...@invisiblethingslab.com/
# [1]
Link:
https://lore.kernel.org/linux-acpi/20230313125344.2893-1-si...@invisiblethingslab.com/
# [2]
Signed-off-by: Simon Gaiser
---
Hi,
I have been looking into using S0ix with Xen. On systems with with 11th
gen (Tiger Lake) Intel mobile CPUs or newer this is often the only
supported suspend method, thus we want to support it in Qubes OS.
Below a summary of my current understanding of what's needed (and known
unknowns). I wou
xenproject.org; marma...@invisiblethingslab.com; Simon
>>> Gaiser
>>> ; Jason Andryuk ; Stefano
>>> Stabellini
>>> ; Anthony Perard ; Paul
>>> Durrant
>>>
>>> Subject: [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
>&
xenproject.org; marma...@invisiblethingslab.com; Simon
>>> Gaiser
>>> ; Jason Andryuk ; Stefano
>>> Stabellini
>>> ; Anthony Perard ; Paul
>>> Durrant
>>>
>>> Subject: [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
>&
Marek Marczykowski-Górecki:
> On Wed, Aug 01, 2018 at 10:36:26AM -0400, Jason Andryuk wrote:
>> On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
>> wrote:
>>> This allows using arguments with spaces, like -append.
>>> Stubdomain side of this require "xenstore-client: Add option for raw
Simon Gaiser:
> Marek Marczykowski-Górecki:
>> On Wed, Aug 01, 2018 at 10:36:26AM -0400, Jason Andryuk wrote:
>>> On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
>>> wrote:
>>>> This allows using arguments with spaces, like -append.
>>
In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>>>>>> I've failed to remember the fact that multiple CPUs share a stub
>>>>>>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>>>>>&
Andrew Cooper:
> On 24/05/18 15:35, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 24/05/18 15:14, Simon Gaiser wrote:
>>>> Jan Beulich:
>>>>>>>> On 24.05.18 at 16:00, wrote:
>>>>>> Jan Beulich:
>>>>>>>
;ve failed to remember the fact that multiple CPUs share a stub
>>>>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>>>>> when bringing down a CPU; it may only be unmapped when no other online
>>>>> CPU uses that same page.
Andrew Cooper:
> On 24/05/18 15:14, Simon Gaiser wrote:
>> Jan Beulich:
>>>>>> On 24.05.18 at 16:00, wrote:
>>>> Jan Beulich:
>>>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>>>> I&#x
fore it is wrong to unconditionally zap the mapping
>>> when bringing down a CPU; it may only be unmapped when no other online
>>> CPU uses that same page.
>>>
>>> Reported-by: Simon Gaiser
>>> Signed-off-by: Jan Beulich
>>>
>>> ---
Jan Beulich:
On 23.05.18 at 00:21, wrote:
>> I have done some more testing in the meantime. The issue also affect
>> 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter.
>> A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and
>> all .data/.rodata/.bss map
George Dunlap:
> On Fri, May 18, 2018 at 5:19 PM, Marek Marczykowski
> wrote:
>> On Fri, May 18, 2018 at 09:54:37AM -0600, Jan Beulich wrote:
>> On 18.05.18 at 17:33, wrote:
Yes, I'm happy to help with that. As I've said, the basic test is very
simple (rtcwake command) and already v
Jason Andryuk:
> On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser
> wrote:
>> Jason Andryuk:
>>> A toolstack may delete the vif frontend and backend xenstore entries
>>> while xen-netfront is in the removal code path. In that case, the
>>> checks fo
Jason Andryuk:
> A toolstack may delete the vif frontend and backend xenstore entries
> while xen-netfront is in the removal code path. In that case, the
> checks for xenbus_read_driver_state would return XenbusStateUnknown, and
> xennet_remove would hang indefinitely. This hang prevents system
>
Andrew Cooper:
> On 15/04/18 16:52, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 14/04/18 06:49, Simon Gaiser wrote:
>>>> Jan Beulich:
>>>>> 1: correct ordering of operations during S3 resume
>>>>> 2: suppress BTI mitigations around
Andrew Cooper:
> On 14/04/18 06:49, Simon Gaiser wrote:
>> Jan Beulich:
>>> 1: correct ordering of operations during S3 resume
>>> 2: suppress BTI mitigations around S3 suspend/resume
>>> 3: check feature flags after resume
>>>
>>> Signed-off
Jan Beulich:
> 1: correct ordering of operations during S3 resume
> 2: suppress BTI mitigations around S3 suspend/resume
> 3: check feature flags after resume
>
> Signed-off-by: Jan Beulich
>
> Simon, could you give this a try please?
Backported to 4.8 it works fine with the two fixes I sent ea
Simon Gaiser:
> Jan Beulich:
>> Make sure no previously present features are missing after resume (and
>> the re-loading of microcode), to avoid later crashes or (likely silent)
>> hangs / live locks. This doesn't go beyond checking x86_capability[],
>> but th
Andrew Cooper:
> On 13/04/18 19:25, Simon Gaiser wrote:
>> Jan Beulich:
>>> NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
>>> may become available only once we're reloaded microcode. Make
>>> SPEC_CTRL_ENTRY_FROM_INTR_IST and DO
Jan Beulich:
> Make sure no previously present features are missing after resume (and
> the re-loading of microcode), to avoid later crashes or (likely silent)
> hangs / live locks. This doesn't go beyond checking x86_capability[],
> but this should be good enough for the immediate need of making s
Jan Beulich:
> NMI and #MC can occur at any time after S3 resume, yet the MSR_SPEC_CTRL
> may become available only once we're reloaded microcode. Make
> SPEC_CTRL_ENTRY_FROM_INTR_IST and DO_SPEC_CTRL_EXIT_TO_XEN no-ops for
> the critical period of time.
>
> Also set the MSR back to its intended v
path, which sits ahead of cpufreq_del_cpu().
Reported-by: Simon Gaiser
Signed-off-by: Jan Beulich
[Simon: Panic if microcode restore fails]
Signed-off-by: Simon Gaiser
---
Sorry didn't want to rewrite the author. No other change in v2.
xen/arch/x86/acpi/power.c | 11 ---
1 file changed
Make it possible to distinguish between a failure to load a microcode
update and a failure to find any matching microcode update by returning
-ENOENT (instead of -EIO) in the later case.
Signed-off-by: Simon Gaiser
---
xen/arch/x86/microcode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
q_del_cpu().
Reported-by: Simon Gaiser
Signed-off-by: Jan Beulich
[Simon: Panic if microcode restore fails]
Signed-off-by: Simon Gaiser
---
xen/arch/x86/acpi/power.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi
Jan Beulich:
>>>> On 11.04.18 at 14:11, wrote:
>>>>> On 11.04.18 at 14:01, wrote:
>>> Andrew Cooper:
>>>> On 11/04/18 12:48, Simon Gaiser wrote:
>>>>> Hi,
>>>>>
>>>>> when I use early microcode load
Andrew Cooper:
> On 11/04/18 12:48, Simon Gaiser wrote:
>> Hi,
>>
>> when I use early microcode loading with the microcode update with the
>> BTI mitigations, resuming from suspend to RAM is broken.
>>
>> Based on added logging to enter_state() (
Hi,
when I use early microcode loading with the microcode update with the
BTI mitigations, resuming from suspend to RAM is broken.
Based on added logging to enter_state() (from power.c) it doesn't
survive the local_irq_restore(flags) call (at least a printk() after the
call doesn't output anythin
xenbus_command_reply() did not actually copy the response string and
leaked stack content instead.
Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response
instead of rc")
Signed-off-by: Simon Gaiser
---
PS: AFAICS this is not a security issue since /dev/xen/xenbus i
By guaranteeing that the argument of XS_TRANSACTION_END is valid we can
assume that the transaction has been closed when we get an XS_ERROR
response from xenstore (Note that we already verify that it's a valid
transaction id).
Signed-off-by: Simon Gaiser
---
drivers/xen/x
have sent XS_TRANSACTION_END once
regardless of the return code.
Cc: # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses")
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Users of the xenbus functions should never close a non existent
transaction (for example by trying to closing the same transaction
twice) but better catch it in xs_request_exit() than to corrupt the
reference counter.
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_xs.c | 4 +++-
1
Juergen Gross:
> On 20/02/18 05:56, Simon Gaiser wrote:
>> Juergen Gross:
>>> On 07/02/18 23:22, Simon Gaiser wrote:
>>>> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
>>>> concurrent xenstore accesses") made a subtle change
smpboot: Fix __max_logical_packages estimate")
>> Signed-off-by: Prarit Bhargava
>> Tested-and-reported-by: Simon Gaiser
>> Cc: Thomas Gleixner
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: x...@kernel.org
>> Cc: Boris Ostrovsky
&g
Juergen Gross:
> On 07/02/18 23:22, Simon Gaiser wrote:
>> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
>> concurrent xenstore accesses") made a subtle change to the semantic of
>> xenbus_dev_request_and_reply() and xenbus_transaction_end().
>&
Boris Ostrovsky:
> On 02/07/2018 05:22 PM, Simon Gaiser wrote:
>> +users_old = xs_state_users;
>> xs_state_users--;
>> if ((req->type == XS_TRANSACTION_START && req->msg.type == XS_ERROR) ||
>> req->type == XS_TRANSACTION_EN
will fail immediately on detecting the error.
Signed-off-by: Simon Gaiser
---
tools/libxc/xc_dom_elfloader.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index c936f92a66..26b2846365 100644
--- a/t
xc_dom_parse_image() does not set errno (at least in many code paths).
So LOGE() is not useful.
Signed-off-by: Simon Gaiser
---
tools/libxl/libxl_dom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ef834e652d
xc_dom_loader.parser() should return elf_negerrnoval.
Signed-off-by: Simon Gaiser
---
tools/libxc/xc_dom_elfloader.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 568d7f370c..c936f92a66
n-devel/2018-01/msg01675.html
Simon Gaiser (3):
libxc: Cleanup xc_dom_parse_elf_kernel()'s return value
libxl: Improve logging in libxl__build_dom()
libxc: xc_dom_parse_elf_kernel: Return error for invalid kernel images
tools/libxc/xc_dom_elfloader.c | 24 +
As the previous commit shows it's quite easy to confuse the transaction
reference counting by ending a transaction twice. So at least try to
detect and report it.
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_xs.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/dr
have sent XS_TRANSACTION_END once
regardless of the return code.
Cc: # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses")
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
n pure pv paths")
Signed-off-by: Simon Gaiser
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 13b4f19b9131..159a897151d6 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@
Prarit Bhargava:
> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>> Prarit Bhargava:
>>> A system booted with a small number of cores enabled per package
>>> panics because the estimate of __max_logical_packages is too low.
>>> This occurs when the total number
Prarit Bhargava:
> A system booted with a small number of cores enabled per package
> panics because the estimate of __max_logical_packages is too low.
> This occurs when the total number of active cores across all packages
> is less than the maximum core count for a single package.
>
> ie) On a 4
George Dunlap:
> On 01/23/2018 04:06 AM, Simon Gaiser wrote:
>> George Dunlap:
>>> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
>>> the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people
>>> able to run PVH ker
George Dunlap:
> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
> the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people
> able to run PVH kernels to switch their PV guests directly to PVH
> guests; and second, eventually enable the backport of patches which
> wil
81 matches
Mail list logo
