On 16.01.2025 16:29, Mikulas Patocka wrote:
>
>
> On Thu, 16 Jan 2025, Jan Beulich wrote:
>
>> On 15.01.2025 19:02, Mikulas Patocka wrote:
>>> On Tue, 14 Jan 2025, Sami Tolvanen wrote:
>>>> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka
>>>>
On 15.01.2025 19:02, Mikulas Patocka wrote:
> On Tue, 14 Jan 2025, Sami Tolvanen wrote:
>> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka wrote:
>>> On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
>>> a module is loaded. The warnings are caused by the fact that the
>>> .
size_t arguments can't compatibly be passed for l-modifier format
specifiers. Use z instead.
Fixes: 8382c668ce4f ("x86/vdso: Add support for exception fixup in vDSO
functions")
Signed-off-by: Jan Beulich
--- a/arch/x86/entry/vdso/vdso2c.h
+++ b/arch/x86/entry/vdso/vdso2c.h
;
> xen_irq_lateeoi(irq, XEN_EOI_FLAG_SPURIOUS);
> }
>
Ah yes, what was originally meant really was
if (!(xenvif_handle_tx_interrupt(queue) |
xenvif_handle_rx_interrupt(queue))) {
(also hinted at by the otherwise pointless inner parentheses),
which you simply write in an alternative way.
Reviewed-by: Jan Beulich
Jan
On 08.02.2021 13:15, Jürgen Groß wrote:
> On 08.02.21 12:54, Jan Beulich wrote:
>> On 08.02.2021 11:59, Jürgen Groß wrote:
>>> On 08.02.21 11:51, Jan Beulich wrote:
>>>> On 08.02.2021 11:41, Jürgen Groß wrote:
>>>>> On 08.02.21 10:48, Jan Beulich wro
On 08.02.2021 11:59, Jürgen Groß wrote:
> On 08.02.21 11:51, Jan Beulich wrote:
>> On 08.02.2021 11:41, Jürgen Groß wrote:
>>> On 08.02.21 10:48, Jan Beulich wrote:
>>>> On 06.02.2021 11:49, Juergen Gross wrote:
>>>>> In evtchn_read() use READ_ONCE()
On 08.02.2021 11:41, Jürgen Groß wrote:
> On 08.02.21 10:48, Jan Beulich wrote:
>> On 06.02.2021 11:49, Juergen Gross wrote:
>>> In evtchn_read() use READ_ONCE() for reading the producer index in
>>> order to avoid the compiler generating multiple accesses.
>>&
On 08.02.2021 11:23, Andrew Cooper wrote:
> On 08/02/2021 09:50, Jan Beulich wrote:
>> On 08.02.2021 10:44, Andrew Cooper wrote:
>>> On 06/02/2021 10:49, Juergen Gross wrote:
>>>> The ring buffer for user events is used in the local system only, so
>>&
On 06.02.2021 11:49, Juergen Gross wrote:
> @@ -1798,6 +1818,29 @@ static void mask_ack_dynirq(struct irq_data *data)
> ack_dynirq(data);
> }
>
> +static void lateeoi_ack_dynirq(struct irq_data *data)
> +{
> + struct irq_info *info = info_for_irq(data->irq);
> + evtchn_port_t evtch
On 08.02.2021 10:44, Andrew Cooper wrote:
> On 06/02/2021 10:49, Juergen Gross wrote:
>> The ring buffer for user events is used in the local system only, so
>> smp barriers are fine for ensuring consistency.
>>
>> Reported-by: Andrew Cooper
>> Signed-off-by: Juergen Gross
>
> These need to be v
On 06.02.2021 11:49, Juergen Gross wrote:
> In evtchn_read() use READ_ONCE() for reading the producer index in
> order to avoid the compiler generating multiple accesses.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/xen/evtchn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On 06.02.2021 11:49, Juergen Gross wrote:
> The ring buffer for user events is used in the local system only, so
> smp barriers are fine for ensuring consistency.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Albeit I think "local
On 27.01.2021 12:33, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 27 January 2021 11:21
>> To: p...@xen.org
>> Cc: 'Paul Durrant' ; 'Konrad Rzeszutek Wilk'
>> ; 'Roger Pau
>> Monné' ; '
On 27.01.2021 12:09, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 27 January 2021 10:57
>> To: Paul Durrant
>> Cc: Paul Durrant ; Konrad Rzeszutek Wilk
>> ; Roger Pau
>> Monné ; Jens Axboe ; Dongli Zhang
>
On 27.01.2021 11:26, Jürgen Groß wrote:
> On 27.01.21 10:43, Andrew Cooper wrote:
>> On 27/01/2021 09:38, Juergen Gross wrote:
>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>>> index 4409306364dc..ca5ac10fcbf7 100644
>>> --- a/arch/x86/xen/enlighten_pv.c
>>> +++ b/arch/
On 27.01.2021 11:30, Paul Durrant wrote:
> From: Paul Durrant
>
> Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
> inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
> behaviour of xen-blkback when connecting to a frontend was:
>
> - read 'ring-p
On 20.01.2021 15:35, Roger Pau Monné wrote:
> On Wed, Jan 20, 2021 at 03:23:30PM +0100, Arthur Borsboom wrote:
>> Hi Roger,
>>
>> I have set up a test environment based on Linux 5.11.0-rc4.
>> The patch did not apply clean, so I copied/pasted the patch manually.
>>
>> Without the patch the call tra
On 22.10.2020 15:09, Jürgen Groß wrote:
> On 22.10.20 12:35, Jan Beulich wrote:
>> On 22.10.2020 11:49, Juergen Gross wrote:
>>> @@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
>>> int ret = -EINVAL;
>>> evtchn_port_t evtchn;
>&g
On 22.10.2020 11:49, Juergen Gross wrote:
> @@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
> int ret = -EINVAL;
> evtchn_port_t evtchn;
>
> - if (fifo_events)
> + if (xen_fifo_events)
> ret = xen_evtchn_fifo_init();
> - if (ret < 0)
> + if (ret <
nts
> xen/events: unmask a fifo event channel only if it was masked
> Documentation: add xen.fifo_events kernel parameter description
With the two remarks to individual patches suitably taken care of
one way or another
Reviewed-by: Jan Beulich
Jan
On 22.10.2020 09:42, Juergen Gross wrote:
> --- a/drivers/xen/events/events_fifo.c
> +++ b/drivers/xen/events/events_fifo.c
> @@ -236,6 +236,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
>
> w = *word;
>
> + if (!(w & (1 << EVTCHN_FIFO_MASKED)))
> + retur
On 22.10.2020 09:42, Juergen Gross wrote:
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -2050,7 +2050,7 @@ void xen_setup_callback_vector(void) {}
> static inline void xen_alloc_callback_vector(void) {}
> #endif
>
> -static bool fifo_events = true;
> +bo
On 15.10.2020 16:59, Jason Andryuk wrote:
> On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich wrote:
>>
>> On 14.10.2020 19:53, Jason Andryuk wrote:
>>> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
>>> Enabling this option may incur a significant performance
On 14.10.2020 19:53, Jason Andryuk wrote:
> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> Enabling this option may incur a significant performance overhead.
>
> config XEN_PVH
> - bool "Support for running as a Xen PVH guest"
> + bool "Xen PVH guest support"
Tangential question: Is "g
On 25.09.2020 15:45, boris.ostrov...@oracle.com wrote:
> On 9/25/20 6:11 AM, Juergen Gross wrote:
>> @@ -1296,6 +1296,14 @@ asmlinkage __visible void __init
>> xen_start_kernel(void)
>>
>> xen_smp_init();
>>
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Disable selecting "Firmware First mo
On 18.08.2020 14:47, Roger Pau Monné wrote:
> On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote:
>> On Mon, Aug 17, 2020 at 11:00:13AM +0200, Roger Pau Monné wrote:
>>> On Sun, Aug 16, 2020 at 02:19:49AM +0200, Marek Marczykowski-Górecki wrote:
In case of Xen PV dom0,
called from init_mem_mapping()) where fixmap
mappings would get established without NX set. For a 32-bit kernel
running in PV mode under Xen this meant a W+X mapping (and associated
warning) for its shared info page mapping established in
xen_pv_init_platform().
Signed-off-by: Jan Beulich
--- a
ssions it is necessary to observe the full
> hierarchy of the page tree.
>
> Introduce a new callback for ptdump which is called for every entry and
> can therefore update the prot_levels array correctly. note_page() can
> then simply access the appropriate element in the array.
&g
Signed-off-by: Jan Beulich
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -366,7 +366,7 @@ static void ptdump_walk_pgd_level_core(s
{0, PTRS_PER_PGD * PGD_LEVEL_MULT / 2},
{GUARD_HOLE_END_ADDR, ~0UL},
#else
- {0, ~0UL},
+ {0, __FIXADDR_
On 12.05.2020 15:02, Steven Price wrote:
> On 12/05/2020 10:39, Jan Beulich wrote:
>> Additionally I'd like to note that note_page()'s "unsigned long val"
>> parameter isn't wide enough for 32-bit PAE PTEs, and hence the NX
>> flag will always be seen
Steven,
in the description of this change you say:
"The effective permissions are passed down the chain using new fields in
struct pg_state."
I don't see how this works, and I suppose this part of the change is
(part of) the reason why a W+X warning has magically disappeared in
5.6.x (compared
nt pt_regs")
Signed-off-by: Jan Beulich
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -48,6 +48,17 @@
#include "calling.h"
+#ifndef CONFIG_XEN_PV
+# define USER_SEGMENT_RPL_MASK SEGMENT_RPL_MASK
+#else
+/*
+ * When running paravirtualized on Xen the kernel
On 02.10.2019 16:14, Boris Ostrovsky wrote:
> On 10/2/19 9:42 AM, Jan Beulich wrote:
>>
>> I can only guess that the thinking probably was that e.g. external
>> dumping (by the tool stack) would be more reliable (including but
>> not limited to this meaning less ch
On 02.10.2019 15:24, Boris Ostrovsky wrote:
> On 10/2/19 3:40 AM, Jan Beulich wrote:
>> On 01.10.2019 17:16, Boris Ostrovsky wrote:
>>> Currently execution of panic() continues until Xen's panic notifier
>>> (xen_panic_event()) is called at which point we make a
On 01.10.2019 17:16, Boris Ostrovsky wrote:
> Currently execution of panic() continues until Xen's panic notifier
> (xen_panic_event()) is called at which point we make a hypercall that
> never returns.
>
> This means that any notifier that is supposed to be called later as
> well as significant p
;
I don't think exporting an __init function is a good idea, and I also
don't see why the function would need exporting had it had the __init
dropped. With the line dropped
Reviewed-by: Jan Beulich
Jan
On 11.09.2019 03:15, Igor Druzhinin wrote:
> Another thing that I implied by "not supporting" but want to explicitly
> call out is that currently Xen will refuse reserving any MCFG area
> unless it actually existed in MCFG table at boot. I don't clearly
> understand reasoning behind it but it might
On 10.09.2019 11:46, Igor Druzhinin wrote:
> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>> On 9/9/19 5:48 PM, Igor Druzhinin wrote:
>>> Actually, pci_mmcfg_late_init() that's called out of acpi_init() -
>>> that's where MCFG areas are properly sized.
>>
>> pci_mmcfg_late_init() reads the (static)
On 06.09.2019 17:55, Andrew Cooper wrote:
> On 06/09/2019 16:39, Arnd Bergmann wrote:
>> HYPERVISOR_platform_op() is an inline function and should not
>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>
>> WARNING: "HYPERVIS
On 04.09.2019 13:36, Igor Druzhinin wrote:
> On 04/09/2019 10:08, Jan Beulich wrote:
>> On 04.09.2019 02:20, Igor Druzhinin wrote:
>>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>>> until Dom0 registers it explicitly after ACPI parser reco
On 04.09.2019 02:20, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820, Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according to "PCI Firmware Spec
On 01.09.2019 08:58, Adam Zerella wrote:
> This resolves a type conversion from 'char *' to 'unsigned short'.
Could you explain this? There's no ...
> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -118,8 +118,8 @@ static enum efi_secureboot_mode
> xen_efi_get_secureboot(void)
>
On 22.07.2019 12:10, Thomas Gleixner wrote:
> On Thu, 11 Jul 2019, Arnd Bergmann wrote:
>
> Trimmed CC list and added Jan
>
>> See below for the patch I am using locally to work around this.
>> That patch is probably wrong, so I have not submitted it yet, but it
>> gives you a clean build ;-)
>>
On 15.07.2019 19:28, Andy Lutomirski wrote:
> On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>>
>> Juergen Gross writes:
>>
>>> The long term plan has been to replace Xen PV guests by PVH. The first
>>> victim of that plan are now 32-bit PV guests, as those are used only
>>> rather seldom thes
On 15.07.2019 07:05, Zhenzhong Duan wrote:
>
> On 2019/7/12 22:06, Andrew Cooper wrote:
>> On 11/07/2019 03:15, Zhenzhong Duan wrote:
>>> Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
>>> selftest") is used to ensure there is a gap setup in exception stack
>>> which could be used
>>> On 12.06.19 at 12:12, wrote:
> When running as a Xen guest selecting "nosmt" either via command line
> or implicitly via default settings makes no sense, as the guest has no
> clue about the real system topology it is running on. With Xen it is
> the hypervisor's job to ensure the proper bug m
>>> On 23.05.19 at 19:27, wrote:
> This fixes 53809751ac23 ("sscanf: don't ignore field widths for numeric
> conversions"). sscanf overflows integers with simple strings such as dates.
> As an example, consider
>
> r = sscanf("20190523123456", "%4d%2d%2d%2d%2d%2d",
> &year, &m
Commit-ID: 547571b5abe61bb33c6005d8981e86e3c61fedcc
Gitweb: https://git.kernel.org/tip/547571b5abe61bb33c6005d8981e86e3c61fedcc
Author: Jan Beulich
AuthorDate: Wed, 27 Mar 2019 09:15:19 -0600
Committer: Ingo Molnar
CommitDate: Wed, 10 Apr 2019 09:53:31 +0200
x86/asm: Modernize
Add missing insn suffixes and use rmwcc.h just like was (more or less)
recently done for bitops.h as well.
Signed-off-by: Jan Beulich
---
v2: Re-base over rmwcc.h changes.
---
arch/x86/include/asm/sync_bitops.h | 31 +--
1 file changed, 9 insertions(+), 22
#x27;t write ptes directly in 32-bit PV
> guests")
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
>>> On 20.02.19 at 23:03, wrote:
> On 2/20/19 9:46 PM, Boris Ostrovsky wrote:
>> On 2/20/19 3:46 PM, Julien Grall wrote:
>>> On 2/20/19 8:04 PM, Boris Ostrovsky wrote:
On 2/20/19 1:05 PM, Julien Grall wrote:
Some sort of a FIFO that stores {irq, data} tuple. It could obviously be
im
>>> On 08.02.19 at 20:58, wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Signed
>>> On 22.01.19 at 09:06, wrote:
> Don't allow memory to be added above the allowed maximum allocation
> limit set by Xen.
This reads as if the hypervisor was imposing a limit here, but looking at
xen_get_max_pages(), xen_foreach_remap_area(), and
xen_count_remap_pages() I take it that it's a res
Commit-ID: fc24d75a7f91837d7918e40719575951820b2b8f
Gitweb: https://git.kernel.org/tip/fc24d75a7f91837d7918e40719575951820b2b8f
Author: Jan Beulich
AuthorDate: Tue, 15 Jan 2019 09:58:16 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 18 Jan 2019 00:39:33 +0100
x86/entry/64/compat
ts.
Fixes: 7f2590a110b837af5679d08fc25c6227c5a8c497
Signed-off-by: Jan Beulich
Cc: sta...@kernel.org
---
v3: Drop NMI path change. Use ALTERNATIVE.
v2: Correct placement of .Lint80_keep_stack label.
---
arch/x86/entry/entry_64_compat.S |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- 5.0-rc
>>> On 13.12.18 at 04:46, wrote:
> On Wed, Dec 12, 2018 at 08:21:39AM -0700, Jan Beulich wrote:
>>>>> On 12.12.18 at 16:18, wrote:
>>> On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
>>>>>>> On 12.12.18 at 08:06, wro
>>> On 12.12.18 at 16:18, wrote:
> On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
>>>>> On 12.12.18 at 08:06, wrote:
>>> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>>>On 12/5/18 4:32 AM, Roger Pau Monné wrote
>>> On 12.12.18 at 08:06, wrote:
> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
I find some pass-thru devices don't work any more across guest reboot.
Assigning
>>> On 21.11.18 at 14:49, wrote:
> From: Jan Beulich
>> Sent: 21 November 2018 13:03
>>
>> >>> On 21.11.18 at 12:55, wrote:
>> > From: Jan Beulich
>> >> Sent: 21 November 2018 10:11
>> >>
>> >> Add missin
>>> On 21.11.18 at 12:55, wrote:
> From: Jan Beulich
>> Sent: 21 November 2018 10:11
>>
>> Add missing insn suffixes and use rmwcc.h just like was (more or less)
>> recently done for bitops.h as well.
>
> Why? bts (etc) on memory don't re
Add missing insn suffixes and use rmwcc.h just like was (more or less)
recently done for bitops.h as well.
Signed-off-by: Jan Beulich
---
v2: Re-base over rmwcc.h changes.
---
arch/x86/include/asm/sync_bitops.h | 31 +--
1 file changed, 9 insertions(+), 22
>>> On 09.07.18 at 10:33, wrote:
> Anyway, normally assembler is the one who chooses instruction
> encoding.
There are different possible views here, and I personally think that
while it is a compiler's job to chose optimal encodings, assemblers
shouldn't by default alter what the programmer (or
>>> On 03.07.18 at 10:46, wrote:
> From: Jan Beulich
>> Sent: 03 July 2018 09:36
> ...
>> As said there, omitting suffixes from instructions in AT&T mode is bad
>> practice when operand size cannot be determined by the assembler from
>> register operands
Commit-ID: a7bea8308933aaeea76dad7d42a6e51000417626
Gitweb: https://git.kernel.org/tip/a7bea8308933aaeea76dad7d42a6e51000417626
Author: Jan Beulich
AuthorDate: Mon, 2 Jul 2018 04:31:54 -0600
Committer: Ingo Molnar
CommitDate: Tue, 3 Jul 2018 09:59:29 +0200
x86/asm/64: Use 32-bit XOR
Commit-ID: 6709812f094d96543b443645c68daaa32d3d3e77
Gitweb: https://git.kernel.org/tip/6709812f094d96543b443645c68daaa32d3d3e77
Author: Jan Beulich
AuthorDate: Mon, 2 Jul 2018 04:47:57 -0600
Committer: Ingo Molnar
CommitDate: Tue, 3 Jul 2018 09:59:29 +0200
x86/entry/64: Add two more
ister operands, and is likely going to be warned about by upstream
gas in the future (mine does already). Add the other missing suffixes
here as well.
Signed-off-by: Jan Beulich
---
arch/x86/entry/entry_64.S |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.18-rc3/arch/x86/en
Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms. Zeroing
idioms don't require execution bandwidth, as they're being taken care
of in the frontend (through register renaming). Use 32-bit XORs instead.
Signed-off-by: Jan Beulich
---
v2: Explain what zeroing idiom
Commit-ID: 236f0cd286b67291796362feeac4f342900cfa82
Gitweb: https://git.kernel.org/tip/236f0cd286b67291796362feeac4f342900cfa82
Author: Jan Beulich
AuthorDate: Mon, 25 Jun 2018 04:21:59 -0600
Committer: Ingo Molnar
CommitDate: Tue, 26 Jun 2018 09:20:31 +0200
x86/entry/32: Add explicit
>>> On 26.06.18 at 09:18, wrote:
> * Jan Beulich wrote:
>
>> Add missing insn suffixes and use rmwcc.h just like was (more or less)
>> recently done for bitops.h as well.
>>
>> Signed-off-by: Jan Beulich
>> ---
>>> On 25.06.18 at 18:33, wrote:
> On 06/25/2018 03:25 AM, Jan Beulich wrote:
>> Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use
>> 32-bit ones instead.
>
> Hmph. Is that considered a bug (errata)?
No.
> URL/references?
Intel'
Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use
32-bit ones instead.
Signed-off-by: Jan Beulich
---
arch/x86/crypto/aegis128-aesni-asm.S |2 +-
arch/x86/crypto/aegis128l-aesni-asm.S|2 +-
arch/x86/crypto/aegis256-aesni-asm.S |2 +-
arch/x86/c
Add missing insn suffixes and use rmwcc.h just like was (more or less)
recently done for bitops.h as well.
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/sync_bitops.h | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
--- 4.18-rc2/arch/x86
Omitting suffixes from instructions in AT&T mode is bad practice when
operand size cannot be determined by the assembler from register
operands, and is likely going to be warned about by upstream gas in the
future (mine does already). Add the single missing suffix here.
Signed-off-by: Jan Beu
>>> On 23.05.18 at 16:30, wrote:
> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
> /* 64-bit entry point. */
> .code64
> 1:
> + /* Set base address in stack canary descriptor. */
> + mov $MSR_GS_BASE,%ecx
> + mov $_pa(canary), %rax
> + xor %rdx, %rdx
Why rax and rdx instea
>>> On 22.05.18 at 19:10, wrote:
> On 05/22/2018 12:32 PM, Jan Beulich wrote:
>>>>> On 22.05.18 at 18:20, wrote:
>>> We are loading virtual address for $canary so we will always have EDX
>>> set to 0x. Isn't that what we want?
>>
>>> On 22.05.18 at 18:20, wrote:
> On 05/22/2018 12:10 PM, Jan Beulich wrote:
>>>>> On 22.05.18 at 17:15, wrote:
>>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
>>>>>>> On 22.05.18 at 15:45, wrote:
>>>>
>>> On 22.05.18 at 17:15, wrote:
> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
>>>>> On 22.05.18 at 15:45, wrote:
>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
>>> wrote:
>>>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
&g
>>> On 22.05.18 at 15:45, wrote:
> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
> wrote:
>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>> /* 64-bit entry point. */
>> .code64
>> 1:
>> + /* Set base address in stack canary descriptor. */
>> + mov $MSR_GS_BASE,%ecx
>>> On 22.05.18 at 05:54, wrote:
> We are making calls to C code (e.g. xen_prepare_pvh()) which may use
> stack canary (stored in GS segment).
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
>>> On 17.05.18 at 19:47, wrote:
> On 05/17/2018 11:02 AM, Jan Beulich wrote:
>>>>> On 17.05.18 at 16:47, wrote:
>>> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
>>> mov %eax,%es
>>> mov %eax,%ss
>>>
>>> + mov $PVH_C
>>> On 17.05.18 at 16:47, wrote:
> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
> mov %eax,%es
> mov %eax,%ss
>
> + mov $PVH_CANARY_SEL,%eax
> + mov %eax,%gs
I doubt this is needed for 64-bit (you could equally well load zero or leave
in place what's there in that case), and loadi
>>> On 16.05.18 at 18:44, wrote:
> Jan Beulich wrote:
>>>>> On 15.05.18 at 16:11, wrote:
>>> --- a/arch/x86/include/asm/refcount.h
>>> +++ b/arch/x86/include/asm/refcount.h
>>> @@ -14,34 +14,43 @@
>>> * central refcount exception
>>> On 15.05.18 at 16:11, wrote:
> --- a/arch/x86/include/asm/refcount.h
> +++ b/arch/x86/include/asm/refcount.h
> @@ -14,34 +14,43 @@
> * central refcount exception. The fixup address for the exception points
> * back to the regular execution flow in .text.
> */
> -#define _REFCOUNT_EXCEPTI
>>> On 09.05.18 at 22:33, wrote:
> @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen)
> mov %eax,%es
> mov %eax,%ss
>
> + /* Set base address in stack canary descriptor. */
> + movl _pa(gdt_start),%eax
> + movl $_pa(canary),%ecx
> + movw %cx, (PVH_GDT_ENTRY_CANARY * 8) + 0(%eax)
>>> On 08.05.18 at 04:38, wrote:
> On Mon, May 7, 2018 at 5:16 AM Jan Beulich wrote:
>
>> While on native entry into the kernel happens on the trampoline stack,
>> PV Xen kernels are being entered with the current thread stack right
>> away. Hence source and de
that code
path is unreachable when running an PV Xen guest afaict.
Signed-off-by: Jan Beulich
Cc: sta...@kernel.org
---
There would certainly have been the option of using alternatives
patching, but afaict the patching code isn't NMI / #MC safe, so I'd
rather stay away from patching
>>> On 02.05.18 at 19:29, wrote:
> On 05/02/2018 11:41 AM, Jan Beulich wrote:
>>>>> On 02.05.18 at 17:22, wrote:
>>> On 05/02/2018 11:01 AM, Jan Beulich wrote:
>>>>>>> On 02.05.18 at 17:00, wrote:
>>>>> On 05/02/
>>> On 02.05.18 at 17:22, wrote:
> On 05/02/2018 11:01 AM, Jan Beulich wrote:
>>>>> On 02.05.18 at 17:00, wrote:
>>> On 05/02/2018 04:16 AM, Jan Beulich wrote:
>>>>>>> On 30.04.18 at 18:23, wrote:
>>>>> --- a/arch/x
>>> On 02.05.18 at 17:08, wrote:
> On 05/02/2018 11:00 AM, Jan Beulich wrote:
>>>>> On 02.05.18 at 16:57, wrote:
>>> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>>>>> On 30.04.18 at 18:23, wrote:
>>>>> Signed-off-by: Bor
>>> On 02.05.18 at 17:06, wrote:
> On 05/02/2018 04:26 AM, Jan Beulich wrote:
>>>>> On 01.05.18 at 14:34, wrote:
>>> On 05/01/2018 04:00 AM, Roger Pau Monné wrote:
>>>> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:
>>>
>>> On 02.05.18 at 17:00, wrote:
> On 05/02/2018 04:16 AM, Jan Beulich wrote:
>>>>> On 30.04.18 at 18:23, wrote:
>>> --- a/arch/x86/xen/xen-pvh.S
>>> +++ b/arch/x86/xen/xen-pvh.S
>>> @@ -54,6 +54,9 @@
>>> * charge of sett
>>> On 02.05.18 at 16:57, wrote:
> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>>> On 30.04.18 at 18:23, wrote:
>>> Signed-off-by: Boris Ostrovsky
>> Reviewed-by: Jan Beulich
>>
>> But to understand why things have been working neverth
>>> On 01.05.18 at 14:34, wrote:
> On 05/01/2018 04:00 AM, Roger Pau Monné wrote:
>> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:
>>> And without it we can't use _BOOT_XX macros any longer so define new ones.
>>
>> Not being that familiar with Linux internals I'm not sure I se
>>> On 30.04.18 at 18:23, wrote:
> And without it we can't use _BOOT_XX macros any longer so define new ones.
Ah, here we go. Perhaps this should be moved earlier in the series?
Assuming you really want to go this route in the first place, taking
Roger's comment into consideration.
Jan
>>> On 30.04.18 at 18:23, wrote:
> --- a/arch/x86/xen/xen-pvh.S
> +++ b/arch/x86/xen/xen-pvh.S
> @@ -54,6 +54,9 @@
> * charge of setting up it's own stack, GDT and IDT.
> */
>
> +#define PVH_GDT_ENTRY_CANARY4
> +#define PVH_CANARY_SEL (PVH_GDT_ENTRY_CANARY * 8)
I can only advis
>>> On 30.04.18 at 18:23, wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
But to understand why things have been working nevertheless it would
have been nice if the commit message wasn't empty, but instead said
something like "The two happen to be identical on 64-bit."
Jan
>>> On 30.04.18 at 18:23, wrote:
> Latest binutils release (2.29.1) will no longer allow proper computation
> of GDT entries on 32-bits, with warning:
>
> arch/x86/xen/xen-pvh.S: Assembler messages:
> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not
> between 0 and 31)
>
>>> On 02.05.18 at 03:56, wrote:
> At 04/27/2018 08:09 PM, Jan Beulich wrote:
>> I'm afraid I don't understand: Limiting the number of disabled CPUs is
>> certainly desirable when those can never be used, but why would you
>> want to do this when they m
>>> On 27.04.18 at 10:32, wrote:
> At 04/27/2018 03:21 PM, Jan Beulich wrote:
>> I've just stumbled across this commit, and I'm wondering if that's actually
>> correct (I too have at least one system where such IDs are reported in
>> MADT): For offli
Hello,
I've just stumbled across this commit, and I'm wondering if that's actually
correct (I too have at least one system where such IDs are reported in
MADT): For offline/absent CPUs, the firmware may not know the APIC IDs
at the point MADT is built, so I think it is quite reasonable to put ~0 i
1 - 100 of 1232 matches
Mail list logo
