On Mon, Apr 28, 2025, at 09:14, Ingo Molnar wrote:
>
> ... and unless I messed up the patch, it seems to have a surprisingly
> low impact - maybe because the compiler can amortize its cost by
> adjusting all dependent code mostly at build time, so the +1 doesn't
> end up being generated most of
On Sat, Apr 26, 2025, at 21:09, Ingo Molnar wrote:
> * Arnd Bergmann wrote:
>
>> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6,
>> Cyrix MII) but also newer embedded Via C3, Geode GX and
>> Vortex86DX/MX/EX/DX2. The replacement Nehemiah (2003)
On Sat, Apr 26, 2025, at 11:08, Ingo Molnar wrote:
> * Arnd Bergmann wrote:
>
> While the simplification is nice on its face, this looks messy:
>
>>
>> config X86_PAE
>> bool "PAE (Physical Address Extension) Support"
>> -depends on X8
On Fri, Apr 25, 2025, at 17:34, H. Peter Anvin wrote:
> On April 25, 2025 7:15:15 AM PDT, Arnd Bergmann wrote:
>
> I really don't like testing an unrelated feature (CMOV for PAE);
How about a new symbol with the opposite polarity, e.g. CONFIG_CPU_586?
In that case, X86_HAVE_PA
From: Arnd Bergmann
With cx8 and tsc being mandatory features, the only important
architectural features are now cmov and pae.
Change the large list of target CPUs to no longer pick the instruction set
itself but only the mtune= optimization level and in-kernel optimizations
that remain
On Mon, Apr 7, 2025, at 20:56, Andrew Davis wrote:
> Hello all,
>
> Continuing the quest to remove the legacy pm_power_off() global
> function handler. Remove uses from arch/arm/ using the helper
> register_platform_power_off().
>
> These have been sent for several cycles without feedback, not
> su
From: Arnd Bergmann
Modules without a description now cause a warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/xen/xenbus/xenbus_probe_frontend.o
Signed-off-by: Arnd Bergmann
---
v2: change the description as suggested by Jürgen
---
drivers/xen/xenbus
From: Arnd Bergmann
Modules without a description now cause a warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/xen/xenbus/xenbus_probe_frontend.o
Signed-off-by: Arnd Bergmann
---
drivers/xen/xenbus/xenbus_probe_frontend.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
On Mon, Mar 3, 2025, at 10:37, Lukas Bulwahn wrote:
> From: Lukas Bulwahn
>
> Commit f388f60ca904 ("x86/cpu: Drop configuration options for early 64-bit
> CPUs") removes the config symbols MCORE2 and MK8.
>
> With that, the references to those two config symbols in xen's x86 Kconfig
> are obsolete
On Thu, Dec 19, 2024, at 12:53, Mark Rutland wrote:
> On Wed, Sep 25, 2024 at 03:58:38PM +0000, Arnd Bergmann wrote:
>> On Wed, Sep 25, 2024, at 15:01, Ard Biesheuvel wrote:
>> > From: Ard Biesheuvel
>>
>> We obviously need to go through all the other version che
res
> elaborate hacks to support.
>
> Signed-off-by: Ard Biesheuvel
> ---
> Documentation/admin-guide/README.rst | 2 +-
> Documentation/process/changes.rst| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Arnd Bergmann
As we discussed during plumbe
On Tue, Dec 5, 2023, at 15:19, Julien Grall wrote:
> On 05/12/2023 14:10, Arnd Bergmann wrote:
>> On Tue, Dec 5, 2023, at 15:01, Julien Grall wrote:
>>> On 05/12/2023 13:59, Jan Beulich wrote:
>>>> On 05.12.2023 14:46, Julien Grall wrote:
>> This would repeat
On Tue, Dec 5, 2023, at 15:01, Julien Grall wrote:
> On 05/12/2023 13:59, Jan Beulich wrote:
>> On 05.12.2023 14:46, Julien Grall wrote:
>>> On 05/12/2023 13:41, Juergen Gross wrote:
On 05.12.23 14:31, Julien Grall wrote:
> Anyway, given you don't seem to have a use-case yet, I would simpl
From: Arnd Bergmann
Xen only supports modern CPUs even when running a 32-bit kernel, and it now
requires a kernel built for a 64 byte (or larger) cache line:
In file included from :
In function 'xen_vcpu_setup',
inlined from 'xen_vcpu_setup_restore' at arch/x86/x
On Tue, Aug 29, 2023, at 14:29, Viresh Kumar via Stratos-dev wrote:
> +/* For privcmd_ioeventfd::flags */
> +#define PRIVCMD_IOEVENTFD_FLAG_DEASSIGN (1 << 0)
> +
> +struct privcmd_ioeventfd {
> + void __user *ioreq;
> + unsigned int __user *ports;
> + __u64 addr;
> + __u32 addr_len
On Wed, May 24, 2023, at 01:09, Boris Ostrovsky wrote:
> On 5/23/23 4:37 PM, Arnd Bergmann wrote:
>> On Sat, May 20, 2023, at 00:24, Boris Ostrovsky wrote:
>>> On 5/19/23 5:28 AM, Arnd Bergmann wrote:
>>
>> Not sure if there is much point for the second one,
From: Arnd Bergmann
These function are all called from assembler files, or from inline assembler,
so there is no immediate need for a prototype in a header, but if
-Wmissing-prototypes
is enabled, the compiler warns about them:
arch/x86/xen/efi.c:130:13: error: no previous prototype for
On Sat, May 20, 2023, at 00:24, Boris Ostrovsky wrote:
> On 5/19/23 5:28 AM, Arnd Bergmann wrote:
>
>> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
>> index 22fb982ff971..81a7821dd07f 100644
>> --- a/arch/x86/xen/smp.h
>> +++ b/arch/x86/xen/smp.h
>> @
On Thu, May 18, 2023, at 23:56, Dave Hansen wrote:
> On 5/16/23 12:35, Arnd Bergmann wrote:
>>
>> All of the warnings have to be addressed in some form before the warning
>> can be enabled by default.
>
> I picked up the ones that were blatantly obvious, but left out
On Thu, May 18, 2023, at 19:28, Dave Hansen wrote:
> On 5/16/23 12:35, Arnd Bergmann wrote:
>>
>> arch/x86/xen/enlighten_pv.c:1233:34: error: no previous prototype for
>> 'xen_start_kernel' [-Werror=missing-prototypes]
>> arch/x86/xen/irq.c:22
From: Arnd Bergmann
These function are all called from assembler files, or from inline assembler,
so there is no immediate need for a prototype in a header, but if
-Wmissing-prototypes
is enabled, the compiler warns about them:
arch/x86/xen/efi.c:130:13: error: no previous prototype for
From: Arnd Bergmann
The xen_debug_interrupt() function is only called on x86, which has a
prototype in an architecture specific header, but the definition also
exists on others, where the lack of a prototype causes a W=1 warning:
drivers/xen/events/events_2l.c:264:13: error: no previous
From: Arnd Bergmann
early_memremap_pgprot_adjust() is a __weak function with a local
prototype, but x86 has a custom implementation that does not
see the prototype, causing a W=1 warning:
arch/x86/mm/ioremap.c:785:17: error: no previous prototype for
'early_memremap_pgprot_adjust'
From: Arnd Bergmann
__vdso_getcpu is declared in a header but this is not included
before the definition, causing a W=1 warning:
arch/x86/entry/vdso/vgetcpu.c:13:1: error: no previous prototype for
'__vdso_getcpu' [-Werror=missing-prototypes]
arch/x86/entry/vdso/vdso32/../vgetcpu.c:1
From: Arnd Bergmann
There are two functions in the olpc platform that have no prototype:
arch/x86/platform/olpc/olpc_dt.c:237:13: error: no previous prototype for
'olpc_dt_fixup' [-Werror=missing-prototypes]
arch/x86/platform/olpc/olpc-xo1-pm.c:73:26: error: no previous pro
From: Arnd Bergmann
copy_mc_fragile_handle_tail() is only called from assembler,
but 'make W=1' complains about a missing prototype:
arch/x86/lib/copy_mc.c:26:1: warning: no previous prototype for
‘copy_mc_fragile_handle_tail’ [-Wmissing-prototypes]
26 | copy_mc_fragile_handle_tai
From: Arnd Bergmann
arch_wb_cache_pmem() is declared in a global header but defined by
the architecture. On x86, the implementation needs to include the header
to avoid this warning:
arch/x86/lib/usercopy_64.c:39:6: error: no previous prototype for
'arch_wb_cache_pmem' [-Werr
From: Arnd Bergmann
The purgatory code has uses parts of the decompressor and provides
its own warn() function, but has to include the corresponding
header file to avoid a -Wmissing-prototypes warning.
It turns out that this the function prototype actually differs
from the declaration, so
From: Arnd Bergmann
fb_is_primary_device() is defined as a global function on x86, unlike
the others that have an inline version. The file that defines is
however needs to include the declaration to avoid a warning:
arch/x86/video/fbdev.c:14:5: error: no previous prototype for
From: Arnd Bergmann
The 32-bit system call entry points can be called on both 32-bit
and 64-bit kernels, but on the former the declarations are hidden:
arch/x86/entry/common.c:238:24: error: no previous prototype for
'do_SYSENTER_32' [-Werror=missing-prototypes]
Move them all
From: Arnd Bergmann
Three functions that are defined in x86 specific code to override
generic __weak implementations cause a warning because of a missing
prototype:
arch/x86/power/cpu.c:298:5: error: no previous prototype for
'hibernate_resume_nonboot_cpu_disable' [-Werror=missing-
From: Arnd Bergmann
__pv_queued_spin_unlock_slowpath is defined in a header file as a global
function, and designed to be called from an inline asm, but there is
no prototype visible in the definition:
kernel/locking/qspinlock_paravirt.h:493:1: error: no previous prototype for
From: Arnd Bergmann
arch_pnpbios_disabled() is defined in architecture code on x86, but this
does not include the appropriate header, causing a warning:
arch/x86/kernel/platform-quirks.c:42:13: error: no previous prototype for
'arch_pnpbios_disabled' [-Werror=missing-prototypes]
Sig
From: Arnd Bergmann
arch/x86/xen/enlighten_pv.c:1233:34: error: no previous prototype for
'xen_start_kernel' [-Werror=missing-prototypes]
arch/x86/xen/irq.c:22:14: error: no previous prototype for
'xen_force_evtchn_callback' [-Werror=missing-prototypes]
arch/x86/xen/mmu_pv
From: Arnd Bergmann
The set_highmem_pages_init() function is declared in asm/numa.h, which
must be included in the file that defines it to avoid a W=1 warning:
arch/x86/mm/highmem_32.c:7:13: error: no previous prototype for
'set_highmem_pages_init' [-Werror=missing-prototypes]
Sig
From: Arnd Bergmann
The fpregs_soft_set/fpregs_soft_get functions are declared in a
header that is not included in the file that defines them, causing
a W=1 warning:
/home/arnd/arm-soc/arch/x86/math-emu/fpu_entry.c:638:5: error: no previous
prototype for 'fpregs_soft_set' [-Werr
From: Arnd Bergmann
Two functions in the 32-bit doublefault code are lacking a prototype:
arch/x86/kernel/doublefault_32.c:23:36: error: no previous prototype for
'doublefault_shim' [-Werror=missing-prototypes]
23 | asmlinkage noinstr void __noreturn doublefault
From: Arnd Bergmann
'make W=1' warns about a function without a prototype in the x86-32 head code:
arch/x86/kernel/head32.c:72:13: error: no previous prototype for
'mk_early_pgtbl_32' [-Werror=missing-prototypes]
This is called from assembler code, so it does not actually
From: Arnd Bergmann
The __div64_32() function is provided for 32-bit architectures that
don't have a custom do_div() implementation. x86_32 has one, and
does not use the header file that declares the function prototype,
so the definition causes a W=1 warning:
lib/math/div64.c:31:32: erro
From: Arnd Bergmann
When CONFIG_SMP is disabled, the prototype for safe_smp_processor_id()
is hidden, which causes a W=1 warning:
/home/arnd/arm-soc/arch/x86/kernel/apic/ipi.c:316:5: error: no previous
prototype for 'safe_smp_processor_id' [-Werror=missing-prototypes]
Since th
From: Arnd Bergmann
Two functions in this file are global but have no prototype in
a header and are not called from elsewhere, so they should
be static:
arch/x86/pci/ce4100.c:86:6: error: no previous prototype for 'sata_revid_init'
[-Werror=missing-prototypes]
arch/x86/pci/ce41
From: Arnd Bergmann
On 32-bit builds, the prepare_ftrace_return() function only has a global
definition, but no prototype before it, which causes a warning:
arch/x86/kernel/ftrace.c:625:6: warning: no previous prototype for
‘prepare_ftrace_return’ [-Wmissing-prototypes]
625 | void
From: Arnd Bergmann
This addresses all x86 specific prototype warnings. The majority of the
patches should be straightforward, either adding an #include statement
to get the right header, or ensuring that an unused global function is
left out of the build when the prototype is hidden.
The ones
On Wed, Jun 8, 2022 at 4:27 PM Peter Zijlstra wrote:
>
> Current arch_cpu_idle() is called with IRQs disabled, but will return
> with IRQs enabled.
>
> However, the very first thing the generic code does after calling
> arch_cpu_idle() is raw_local_irq_disable(). This means that
> architectures th
On Wed, Jun 8, 2022 at 4:27 PM Peter Zijlstra wrote:
>
> arch_cpu_idle() is a very simple idle interface and exposes only a
> single idle state and is expected to not require RCU and not do any
> tracing/instrumentation.
>
> As such, omap_sram_idle() is not a valid implementation. Replace it
> wit
On Wed, May 18, 2022 at 5:06 PM Oleksandr wrote:
> On 18.05.22 17:32, Arnd Bergmann wrote:
> > On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko
> > wrote:
>
> > This would mean having a device
> > node for the grant-table mechanism that can be refe
On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko wrote:
>
> diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml
> b/Documentation/devicetree/bindings/virtio/mmio.yaml
> index 10c22b5..29a0932 100644
> --- a/Documentation/devicetree/bindings/virtio/mmio.yaml
> +++ b/Documentation/de
From: Arnd Bergmann
The #ifdef check around the definition doesn't match the one around the
declaration, leading to a link failure when CONFIG_XEN_DOM0 is enabled
but CONFIG_XEN_PV_DOM0 is not:
x86_64-linux-ld: arch/x86/kernel/apic/msi.o: in function
`arch_restore_msi_irqs':
msi.c:(.
t; Cc: Nishanth Menon
> Cc: Tero Kristo
> Cc: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org
Acked-by: Arnd Bergmann
; Cc: Vinod Koul
> Cc: dmaeng...@vger.kernel.org
Acked-by: Arnd Bergmann
it. The other MSI specific
> parts are going to be removed from struct device in later steps.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
Acked-by: Arnd Bergmann
On Fri, Dec 10, 2021 at 11:18 PM Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
> Cc: Arnd Bergmann
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: linuxppc-...@lists.oz
From: Arnd Bergmann
In configurations with CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=n
and CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y, gcc warns about an
unused variable:
drivers/xen/balloon.c:83:12: error: 'xen_hotplug_unpopulated' defined but not
used [-Werror=unused-variable]
Since this is a
From: Arnd Bergmann
There are hundreds of warnings in a W=2 build about a local
variable shadowing the global 'apic' definition:
arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
declaration [-Wshadow]
Avoid this by renaming the global 'a
On Thu, Oct 29, 2020 at 8:04 AM Paolo Bonzini wrote:
>
> On 28/10/20 22:20, Arnd Bergmann wrote:
> > Avoid this by renaming the global 'apic' variable to the more descriptive
> > 'x86_system_apic'. It was originally called 'genapic', but both tha
From: Arnd Bergmann
There are hundreds of warnings in a W=2 build about a local
variable shadowing the global 'apic' definition:
arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
declaration [-Wshadow]
Avoid this by renaming the global 'a
On Mon, Jul 13, 2020 at 3:22 PM Saheed O. Bolarinwa
wrote:
> This goal of these series is to move the definition of *all* PCIBIOS* from
> include/linux/pci.h to arch/x86 and limit their use within there.
> All other tree specific definition will be left for intact. Maybe they can
> be renamed.
>
>
On Wed, May 6, 2020 at 7:12 AM Jürgen Groß wrote:
>
> On 05.05.20 22:57, Arnd Bergmann wrote:
> > On Tue, May 5, 2020 at 6:02 PM Jürgen Groß wrote:
> >> On 05.05.20 17:01, Arnd Bergmann wrote:
> >>> On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
> >>
On Tue, May 5, 2020 at 6:02 PM Jürgen Groß wrote:
> On 05.05.20 17:01, Arnd Bergmann wrote:
> > On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
> >> On 05.05.20 16:15, Arnd Bergmann wrote:
> >
> > I considered that as well, and don't really mind either way.
On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote:
> On 05.05.20 16:15, Arnd Bergmann wrote:
> > The __xenbus_map_ring() function has two large arrays, 'map' and
> > 'unmap' on its stack. When clang decides to inline it into its caller,
> > xenbus_map
n total, regardless of the
inlining decision.
Signed-off-by: Arnd Bergmann
---
drivers/xen/xenbus/xenbus_client.c | 74 +-
1 file changed, 41 insertions(+), 33 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 040d
no arguments are passed, the
same handler can be used for .ioctl and .compat_ioctl, and
when only pointer arguments are passed, the newly added
blkdev_compat_ptr_ioctl can be used.
Signed-off-by: Arnd Bergmann
---
drivers/block/floppy.c | 3 +++
drivers/block/paride/pd.c| 1 +
drivers
need a compat_ptr() conversion,
introduce a blkdev_compat_ptr_ioctl() helper function that
can be used as the .compat_ioctl callback for those drivers
that only support compatible commands.
The actual CD-ROM drivers that call cdrom_ioctl() are
converted in a separate patch.
Signed-off-by: Arnd
nel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=compat-ioctl-endgame
Arnd Bergmann (24):
compat: ARM64: always include asm-generic/compat.h
compat: scsi: sg: fix v3 compat read/write interface
compat_ioctl: block: handle BLKREPORTZONE/BLKRESETZONE
compat_ioctl: block: hand
On Tue, Oct 1, 2019 at 7:38 PM Stefano Stabellini
wrote:
> Thank you for the patch. HYPERVISOR_platform_op() is an inline function,
> the underlying function that should be exported is
> HYPERVISOR_platform_op_raw. So, instead of removing
> HYPERVISOR_platform_op, we should change it to
> HYPERVI
On Fri, Sep 6, 2019 at 5:55 PM 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* funct
neous export.
Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
Signed-off-by: Arnd Bergmann
---
arch/arm/xen/enlighten.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 1e57692552d9..845c528acf24 100644
Gross and Boris Ostrovsky.
Signed-off-by: Arnd Bergmann
---
v2: rename mm.o to xen-builtin.o, make it unconditional
v3: move new code into xlate_mmu as suggested by Boris Ostrovsky.
sorry for the long delay since v2, I lost track of this.
---
drivers/xen/privcm
6/include/asm/pgtable_32.h:98:34: note: expanded from macro
'PAGE_TABLE_SIZE'
#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
Use the _ULL() macro to make it a 64-bit constant.
Fixes: 1e620f9b23e5 ("x86/boot/32: Convert the 32-bit pgtable setup code from
assembly to C&
wer type,
and use the same expression in the error handling later.
Fixes: b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR")
Signed-off-by: Arnd Bergmann
---
I still think that reverting the original commit would have
provided clearer semantics for this corner case, but at least
this pat
On Wed, Mar 13, 2019 at 7:33 PM Christoph Hellwig wrote:
> On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote:
> > In the common case, Dom0 also contains the PV backend drivers. Those
> > drivers may directly use the guest buffer in the DMA request (so a copy is
> > avoided). To avoid us
On Tue, Mar 5, 2019 at 3:57 PM Juergen Gross wrote:
> On 05/03/2019 14:43, Boris Ostrovsky wrote:
> > On 3/5/19 8:30 AM, Arnd Bergmann wrote:
> >> @@ -809,15 +789,7 @@ static long privcmd_ioctl_mmap_resource(struct file
> >> *file, void __user *udata)
rgen Gross. Additional code will
be moved into this file later.
Signed-off-by: Arnd Bergmann
---
v2: rename mm.o to xen-builtin.o, make it unconditional
---
drivers/xen/Makefile | 1 +
drivers/xen/privcmd.c | 30 +---
drivers/xen/xen-buil
On Tue, Mar 5, 2019 at 10:05 AM Juergen Gross wrote:
>
> On 05/03/2019 09:34, Arnd Bergmann wrote:
> > On Tue, Mar 5, 2019 at 7:39 AM Juergen Gross wrote:
> >
> >>
> >> Can we avoid that ifdef in the Makefile?
> >>
> >> I'd rather
On Tue, Mar 5, 2019 at 7:39 AM Juergen Gross wrote:
>
> Can we avoid that ifdef in the Makefile?
>
> I'd rather have an architecture independant builtin driver added which
> is always included for CONFIG_XEN. This would allow to move redundant
> stuff from arch/*/xen/ into it (e.g. xen_vcpu_id).
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote:
> On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
> > This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"),
> > which
> > introduced an overflow warning in configurations that have a larger
On Mon, Mar 4, 2019 at 10:19 PM Boris Ostrovsky
wrote:
>
> On 3/4/19 3:47 PM, Arnd Bergmann wrote:
> > Building the privcmd code as a loadable module on ARM, we get
> > a link error due to the private cache management functions:
> >
> > ERROR: "__sync_icache_
ses, at the time when they were in use, only
a patched kernel was supported anyway.
Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for very old
hypervisors")
Reviewed-by: Boris Ostrovsky
Cc: Jan Beulich
Signed-off-by: Arnd Bergmann
---
[v2] use a table lookup
n when the latter is a loadable module.
xen_remap_vma_range() may not be the best name here, if someone
comes up with a better one, let me know.
Signed-off-by: Arnd Bergmann
---
drivers/xen/Makefile | 3 +++
drivers/xen/mm.c | 41 +
drivers/xen/priv
bled hardware platforms, while the physical
address space depends on the type of MMU chosen (classic vs LPAE).
I tried a couple of alternative approaches, but the previous version
seems as good as any other, so I went back to that.
Fixes: b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR&q
On Tue, May 29, 2018 at 7:58 AM, Oleksandr Andrushchenko
wrote:
> On 05/25/2018 06:50 PM, Arnd Bergmann wrote:
>> b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>> index 8099cb343ae3..d333b67cc1a0 100644
>> --- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>>
is a bit safer.
Fixes: fd3b36045c2c ("ALSA: xen-front: Read sound driver configuration from Xen
store")
Signed-off-by: Arnd Bergmann
---
sound/xen/xen_snd_front_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/xen/xen_snd_front_cfg.c b/sound/xen/xen_snd_fron
ing uintptr_t instead probably does what we want here, although it's
not clear to me why we assign a virtual address pointer to a phys_addr_t
in backend_unmap().
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Arnd Bergmann
---
On Sat, Apr 28, 2018 at 12:21 AM, Joao Martins
wrote:
> On 04/27/2018 09:13 PM, Arnd Bergmann wrote:
>> diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
>> index 761f6af6efa5..637982efecd8 100644
>> --- a/arch/x86/kernel/pvclock.c
>> +++ b/arch/x86/ker
to communicate the boot time between host and guest
in a virtual environment. This will work until 2106, but we
should ideally find a replacement anyway. I've added a comment
about it there.
Reviewed-by: Boris Ostrovsky
Signed-off-by: Arnd Bergmann
---
v2 changes:
- move comment block (
ses, at the time when they were in use, only
a patched kernel was supported anyway.
Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for very old
hypervisors")
Signed-off-by: Arnd Bergmann
---
[v2] use a table lookup instead of a switch/case statement, after
multiple su
On Fri, Feb 9, 2018 at 3:13 PM, David Laight wrote:
> From: Arnd Bergmann
>> Sent: 09 February 2018 12:58
> ...
>> However, aside from this driver, I wonder if we should be worried about
>> Spectre type 1 attacks on similar code, when gcc-8 turns a switch/case
>>
On Mon, Feb 5, 2018 at 4:14 PM, Andrew Cooper wrote:
> On 05/02/18 15:03, Arnd Bergmann wrote:
>
> Snipping deleted code to make things clearer:
>
>> + if (cmd > ARRAY_SIZE(physdevop_len))
>> + return -ENOSYS;
>>
>> + len = physdevop_le
On Mon, Feb 5, 2018 at 4:14 PM, Jan Beulich wrote:
On 05.02.18 at 16:03, wrote:
>> int xen_event_channel_op_compat(int cmd, void *arg)
>> {
>> - struct evtchn_op op;
>> + struct evtchn_op op = { .cmd = cmd, };
>> + size_t len;
>> int rc;
>>
>> - op.cmd = cmd;
>> -
the functions so that each argument is accessed with
exactly the correct length based on the command code.
Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for very old
hypervisors")
Signed-off-by: Arnd Bergmann
---
[v2] use a table lookup instea
On Mon, Feb 5, 2018 at 2:58 PM, David Laight wrote:
> From: Arnd Bergmann
>> Sent: 05 February 2018 12:37
>
>> > Are the EVTCHNOP_xxx values dense?
>> > In which case an array is almost certainly better than the switch
>> > statement.
>>
>>
On Mon, Feb 5, 2018 at 1:11 PM, David Laight wrote:
> From: Boris Ostrovsky
>> Sent: 02 February 2018 23:34
> ...
>> > switch (cmd) {
>> > + case EVTCHNOP_bind_interdomain:
>> > + len = sizeof(struct evtchn_bind_interdomain);
>> > + break;
>> > + case EVTCHNOP_bind_virq
On Sat, Feb 3, 2018 at 6:08 PM, Boris Ostrovsky
wrote:
>
>
> On 02/03/2018 10:12 AM, Arnd Bergmann wrote:
>>
>> On Sat, Feb 3, 2018 at 12:33 AM, Boris Ostrovsky
>> wrote:
>>>
>>> On 02/02/2018 10:32 AM, Arnd Bergmann wrote:
>>>>
>
On Sat, Feb 3, 2018 at 12:33 AM, Boris Ostrovsky
wrote:
> On 02/02/2018 10:32 AM, Arnd Bergmann wrote:
>> The legacy hypercall handlers were originally added with
>> a comment explaining that "copying the argument structures in
>> HYPERVISOR_event_channel_op() and HYPERV
On Fri, Feb 2, 2018 at 4:53 PM, Dan Carpenter wrote:
> On Fri, Feb 02, 2018 at 04:32:31PM +0100, Arnd Bergmann wrote:
>> --- a/drivers/xen/fallback.c
>> +++ b/drivers/xen/fallback.c
>> @@ -7,75 +7,87 @@
>>
>> int xen_event_channel_op_compat(int cmd, void *arg)
&
the functions so that each argument is accessed with
exactly the correct length based on the command code.
Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for very old
hypervisors")
Signed-off-by: Arnd Bergmann
---
drivers/xen/fallback.c | 94 +
96 matches
Mail list logo
