[PATCH] x86/vdso: avoid warning when building vdso2c on 32-bit host

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 @@ -

Re: [PATCH v2 4/8] xen/netback: fix spurious event detection for common event case

n_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

Re: [PATCH 7/7] xen/evtchn: read producer index only once

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

Re: [PATCH 7/7] xen/evtchn: read producer index only once

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()

Re: [PATCH 7/7] xen/evtchn: read producer index only 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. >>&

Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring

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 >>&

Re: [PATCH 2/7] xen/events: don't unmask an event channel when an eoi is pending

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

Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring

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

Re: [PATCH 7/7] xen/evtchn: read producer index only once

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(-) > >

Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring

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

Re: [PATCH] xen-blkback: fix compatibility bug with single page rings

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é' ; 'Jens Axboe' ; 'Dongli Zhang' >&

Re: [PATCH] xen-blkback: fix compatibility bug with single page rings

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 >

Re: [PATCH v2] x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled

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 >>> +++

Re: [PATCH] xen-blkback: fix compatibility bug with single page rings

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

Re: [PATCH v2] xen-blkfront: allow discard-* nodes to be optional

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

Re: [PATCH v2 3/5] xen/events: only register debug interrupt for 2-level events

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 ev

Re: [PATCH v2 3/5] xen/events: only register debug interrupt for 2-level events

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 <

Re: [PATCH 0/5] xen: event handling cleanup

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

Re: [PATCH 4/5] xen/events: unmask a fifo event channel only if it was masked

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))) > +

Re: [PATCH 3/5] xen/events: only register debug interrupt for 2-level events

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; >

Re: [PATCH 1/2] xen: Remove Xen PVH/PVHVM dependency on PCI

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

Re: [PATCH 1/2] xen: Remove Xen PVH/PVHVM dependency on PCI

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

Re: [PATCH] x86/xen: disable Firmware First mode for correctable memory errors

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

Re: [PATCH] efi: discover ESRT table on Xen PV too

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,

[PATCH] x86/mm: keep __default_kernel_pte_mask in sync with __supported_pte_mask

(), as 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

Re: [PATCH 1/2] x86: mm: ptdump: Calculate effective permissions correctly

permissions 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

[PATCH] ix86: keep page table dumping off hypervisor area

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_TOP +

Re: your "x86: mm: convert dump_pagetables to use walk_page_range" change

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 as clear in ne

your "x86: mm: convert dump_pagetables to use walk_page_range" change

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

[PATCH] x86/stackframe/32: repair 32-bit Xen PV

_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 runs

Re: [Xen-devel] [PATCH] x86/xen: Return from panic notifier

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 les

Re: [Xen-devel] [PATCH] x86/xen: Return from panic notifier

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 hyper

Re: [Xen-devel] [PATCH] x86/xen: Return from panic notifier

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

Re: [Xen-devel] [PATCH] xen/efi: have a common runtime setup function

tup); 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

Re: [Xen-devel] [PATCH] xen/pci: try to reserve MCFG areas earlier

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

Re: [Xen-devel] [PATCH] xen/pci: try to reserve MCFG areas earlier

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

Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function

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:

Re: [PATCH] xen/pci: try to reserve MCFG areas earlier

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

Re: [PATCH] xen/pci: try to reserve MCFG areas earlier

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

Re: [Xen-devel] [PATCH] x86/xen/efi: Fix EFI variable 'name' type conversion

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) >

Re: [PATCH] vsyscall: use __iter_div_u64_rem()

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 ;-) >>

Re: [Xen-devel] [PATCH 0/2] Remove 32-bit Xen PV guest support

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

Re: [Xen-devel] [PATCH v2] xen/pv: Fix a boot up hang revealed by int3 self test

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

Re: [Xen-devel] [PATCH] x86/xen: disable nosmt in Xen guests

>>> 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

Re: [PATCH RFC] sscanf: Fix integer overflow with sscanf field width

>>> 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", > , , , >

[tip:x86/asm] x86/asm: Modernize sync_bitops.h

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

[PATCH v2 RESEND] x86: modernize sync_bitops.h

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

Re: [Xen-devel] [PATCH] xen: fix dom0 boot on huge systems

te ptes directly in 32-bit PV > guests") > Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich

Re: xen/evtchn and forced threaded irq

>>> 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

Re: [Xen-devel] [PATCH net-next] xen-netback: mark expected switch fall-through

>>> 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. > >

Re: [Xen-devel] [PATCH 2/2] x86/xen: dont add memory above max allowed allocation

>>> 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

[tip:x86/urgent] x86/entry/64/compat: Fix stack switching for XEN PV

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

[PATCH v3] x86-64/Xen: fix stack switching

: 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-rc2/arch/x86

Re: [PATCH] xen: xen-pciback: Reset MSI-X state when exposing a device

>>> 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

Re: [PATCH] xen: xen-pciback: Reset MSI-X state when exposing a device

>>> 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

Re: [PATCH] xen: xen-pciback: Reset MSI-X state when exposing a device

>>> 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

RE: [PATCH v2] x86: modernize sync_bitops.h

>>> 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 mi

RE: [PATCH v2] x86: modernize sync_bitops.h

>>> 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 mi

RE: [PATCH v2] x86: modernize sync_bitops.h

>>> 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 really

RE: [PATCH v2] x86: modernize sync_bitops.h

>>> 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 really

[PATCH v2] x86: modernize sync_bitops.h

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

[PATCH v2] x86: modernize sync_bitops.h

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

Re: [PATCH v2] x86-64: use 32-bit XOR to zero registers

>>> 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

Re: [PATCH v2] x86-64: use 32-bit XOR to zero registers

>>> 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

RE: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes

>>> 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 mode is bad >> practice when operand size cannot be determined by the assembler from >> register operands,

RE: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes

>>> 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 mode is bad >> practice when operand size cannot be determined by the assembler from >> register operands,

[tip:x86/asm] x86/asm/64: Use 32-bit XOR to zero registers

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

[tip:x86/asm] x86/entry/64: Add two more instruction suffixes

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

[tip:x86/asm] x86/asm/64: Use 32-bit XOR to zero registers

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

[tip:x86/asm] x86/entry/64: Add two more instruction suffixes

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

[PATCH] x86/entry/64: add two more instruction suffixes

r 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/entry/

[PATCH] x86/entry/64: add two more instruction suffixes

r 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/entry/

[PATCH v2] x86-64: use 32-bit XOR to zero registers

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 idioms are/do

[PATCH v2] x86-64: use 32-bit XOR to zero registers

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 idioms are/do

[tip:x86/urgent] x86/entry/32: Add explicit 'l' instruction suffix

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

[tip:x86/urgent] x86/entry/32: Add explicit 'l' instruction suffix

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

Re: [PATCH] x86: modernize sync_bitops.h

>>> 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 >> ---

Re: [PATCH] x86: modernize sync_bitops.h

>>> 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 >> ---

Re: [PATCH] x86-64: use 32-bit XOR to zero registers

>>> 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's Opti

Re: [PATCH] x86-64: use 32-bit XOR to zero registers

>>> 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's Opti

[PATCH] x86-64: use 32-bit XOR to zero registers

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/crypto

[PATCH] x86-64: use 32-bit XOR to zero registers

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/crypto

[PATCH] x86: modernize sync_bitops.h

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

[PATCH] x86: modernize sync_bitops.h

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

[PATCH] ix86/entry: add instruction suffix

Omitting suffixes from instructions in AT 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 Beulich

[PATCH] ix86/entry: add instruction suffix

Omitting suffixes from instructions in AT 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 Beulich

Re: [PATCH v5 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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,

Re: [PATCH v5 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 22.05.18 at 19:10, <boris.ostrov...@oracle.com> wrote: > On 05/22/2018 12:32 PM, Jan Beulich wrote: >>>>> On 22.05.18 at 18:20, <boris.ostrov...@oracle.com> wrote: >>> We are loading virtual address for $canary so we will always have EDX >&

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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? >>

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 22.05.18 at 18:20, <boris.ostrov...@oracle.com> wrote: > On 05/22/2018 12:10 PM, Jan Beulich wrote: >>>>> On 22.05.18 at 17:15, <brge...@gmail.com> wrote: >>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich <jbeul...@suse.com> wrote: &

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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: >>>>

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 22.05.18 at 17:15, <brge...@gmail.com> wrote: > On Tue, May 22, 2018 at 9:57 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>> On 22.05.18 at 15:45, <brge...@gmail.com> wrote: >>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky >>

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 22.05.18 at 05:54, <boris.ostrov...@oracle.com> 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 <boris.ostrov...@oracle.com> Reviewed-by: Jan Beulich <jbeul...@suse.com>

Re: [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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

Re: [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 17.05.18 at 19:47, <boris.ostrov...@oracle.com> wrote: > On 05/17/2018 11:02 AM, Jan Beulich wrote: >>>>> On 17.05.18 at 16:47, <boris.ostrov...@oracle.com> wrote: >>> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen) >>> mov %eax,%es &g

Re: [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

>>> 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

  1   2   3   4   5   6   7   8   9   10   >