04 Jan, 2021

1 commit

  • This is the 5.10.4 stable release

    * tag 'v5.10.4': (717 commits)
    Linux 5.10.4
    x86/CPU/AMD: Save AMD NodeId as cpu_die_id
    drm/edid: fix objtool warning in drm_cvt_modes()
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    drivers/gpu/drm/imx/dcss/dcss-plane.c
    drivers/media/i2c/ov5640.c

    Jason Liu
     

30 Dec, 2020

3 commits

  • commit 3dc86ca6b4c8cfcba9da7996189d1b5a358a94fc upstream.

    This commit adds a counter of pending messages for each watch in the
    struct. It is used to skip unnecessary pending messages lookup in
    'unregister_xenbus_watch()'. It could also be used in 'will_handle'
    callback.

    This is part of XSA-349

    Cc: stable@vger.kernel.org
    Signed-off-by: SeongJae Park
    Reported-by: Michael Kurth
    Reported-by: Pawel Wieczorkiewicz
    Reviewed-by: Juergen Gross
    Signed-off-by: Juergen Gross
    Signed-off-by: Greg Kroah-Hartman

    SeongJae Park
     
  • commit 2e85d32b1c865bec703ce0c962221a5e955c52c2 upstream.

    Some code does not directly make 'xenbus_watch' object and call
    'register_xenbus_watch()' but use 'xenbus_watch_path()' instead. This
    commit adds support of 'will_handle' callback in the
    'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'.

    This is part of XSA-349

    Cc: stable@vger.kernel.org
    Signed-off-by: SeongJae Park
    Reported-by: Michael Kurth
    Reported-by: Pawel Wieczorkiewicz
    Reviewed-by: Juergen Gross
    Signed-off-by: Juergen Gross
    Signed-off-by: Greg Kroah-Hartman

    SeongJae Park
     
  • commit fed1755b118147721f2c87b37b9d66e62c39b668 upstream.

    If handling logics of watch events are slower than the events enqueue
    logic and the events can be created from the guests, the guests could
    trigger memory pressure by intensively inducing the events, because it
    will create a huge number of pending events that exhausting the memory.

    Fortunately, some watch events could be ignored, depending on its
    handler callback. For example, if the callback has interest in only one
    single path, the watch wouldn't want multiple pending events. Or, some
    watches could ignore events to same path.

    To let such watches to volutarily help avoiding the memory pressure
    situation, this commit introduces new watch callback, 'will_handle'. If
    it is not NULL, it will be called for each new event just before
    enqueuing it. Then, if the callback returns false, the event will be
    discarded. No watch is using the callback for now, though.

    This is part of XSA-349

    Cc: stable@vger.kernel.org
    Signed-off-by: SeongJae Park
    Reported-by: Michael Kurth
    Reported-by: Pawel Wieczorkiewicz
    Reviewed-by: Juergen Gross
    Signed-off-by: Juergen Gross
    Signed-off-by: Greg Kroah-Hartman

    SeongJae Park
     

14 Dec, 2020

2 commits

  • Add i2c backend frontend support.
    The transaction only support one msg each time.
    The frontend sends a request to backend, backend use i2c_transfer
    to do real transaction to hardware and return the results to frontend.

    Now i2cdump/get/set works.
    In domu cfg file, use
    "vi2c = ['backend=0,be-adapter=5a800000.i2c,addr=0x51;0x44']" to
    create a dummy controller in frontend and allowed slaves in backend.

    Currently the slave address check not added, it will be supported in
    furture patch.

    Signed-off-by: Peng Fan
    Acked-by: Leonard Crestez

    Peng Fan
     
  • Introduce i2cif from xen. This will be used by paravirtualization
    i2c driver.

    Signed-off-by: Peng Fan
    Acked-by: Leonard Crestez

    Peng Fan
     

09 Dec, 2020

2 commits

  • Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated
    memory") introduced usage of ZONE_DEVICE memory for foreign memory
    mappings.

    Unfortunately this collides with using page->lru for Xen backend
    private page caches.

    Fix that by using page->zone_device_data instead.

    Cc: # 5.9
    Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory")
    Signed-off-by: Juergen Gross
    Reviewed-by: Boris Ostrovsky
    Reviewed-by: Jason Andryuk
    Signed-off-by: Juergen Gross

    Juergen Gross
     
  • Instead of having similar helpers in multiple backend drivers use
    common helpers for caching pages allocated via gnttab_alloc_pages().

    Make use of those helpers in blkback and scsiback.

    Cc: # 5.9
    Signed-off-by: Juergen Gross
    Reviewed-by: Boris Ostrovsky
    Signed-off-by: Juergen Gross

    Juergen Gross
     

26 Oct, 2020

1 commit

  • Pull more xen updates from Juergen Gross:

    - a series for the Xen pv block drivers adding module parameters for
    better control of resource usge

    - a cleanup series for the Xen event driver

    * tag 'for-linus-5.10b-rc1c-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
    Documentation: add xen.fifo_events kernel parameter description
    xen/events: unmask a fifo event channel only if it was masked
    xen/events: only register debug interrupt for 2-level events
    xen/events: make struct irq_info private to events_base.c
    xen: remove no longer used functions
    xen-blkfront: Apply changed parameter name to the document
    xen-blkfront: add a parameter for disabling of persistent grants
    xen-blkback: add a parameter for disabling of persistent grants

    Linus Torvalds
     

23 Oct, 2020

1 commit

  • With the switch to the lateeoi model for interdomain event channels
    some functions are no longer in use. Remove them.

    Suggested-by: Jan Beulich
    Signed-off-by: Juergen Gross
    Reviewed-by: Jan Beulich
    Link: https://lore.kernel.org/r/20201022094907.28560-2-jgross@suse.com
    Signed-off-by: Boris Ostrovsky

    Juergen Gross
     

21 Oct, 2020

1 commit

  • Pull more xen updates from Juergen Gross:

    - A single patch to fix the Xen security issue XSA-331 (malicious
    guests can DoS dom0 by triggering NULL-pointer dereferences or access
    to stale data).

    - A larger series to fix the Xen security issue XSA-332 (malicious
    guests can DoS dom0 by sending events at high frequency leading to
    dom0's vcpus being busy in IRQ handling for elongated times).

    * tag 'for-linus-5.10b-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
    xen/events: block rogue events for some time
    xen/events: defer eoi in case of excessive number of events
    xen/events: use a common cpu hotplug hook for event channels
    xen/events: switch user event channels to lateeoi model
    xen/pciback: use lateeoi irq binding
    xen/pvcallsback: use lateeoi irq binding
    xen/scsiback: use lateeoi irq binding
    xen/netback: use lateeoi irq binding
    xen/blkback: use lateeoi irq binding
    xen/events: add a new "late EOI" evtchn framework
    xen/events: fix race in evtchn_fifo_unmask()
    xen/events: add a proper barrier to 2-level uevent unmasking
    xen/events: avoid removing an event channel while handling it

    Linus Torvalds
     

20 Oct, 2020

1 commit

  • In order to avoid tight event channel related IRQ loops add a new
    framework of "late EOI" handling: the IRQ the event channel is bound
    to will be masked until the event has been handled and the related
    driver is capable to handle another event. The driver is responsible
    for unmasking the event channel via the new function xen_irq_lateeoi().

    This is similar to binding an event channel to a threaded IRQ, but
    without having to structure the driver accordingly.

    In order to support a future special handling in case a rogue guest
    is sending lots of unsolicited events, add a flag to xen_irq_lateeoi()
    which can be set by the caller to indicate the event was a spurious
    one.

    This is part of XSA-332.

    Cc: stable@vger.kernel.org
    Reported-by: Julien Grall
    Signed-off-by: Juergen Gross
    Reviewed-by: Jan Beulich
    Reviewed-by: Stefano Stabellini
    Reviewed-by: Wei Liu

    Juergen Gross
     

07 Oct, 2020

1 commit

  • Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
    address conversion.

    In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
    to gfn by virt_to_gfn() macro. However, since the virt_to_gfn(v)
    assumes the given virtual address is in linear mapped kernel memory
    area, it can not convert the per-cpu memory if it is allocated on
    vmalloc area.

    This depends on CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK.
    If it is enabled, the first chunk of percpu memory is linear mapped.
    In the other case, that is allocated from vmalloc area. Moreover,
    if the first chunk of percpu has run out until allocating
    xen_vcpu_info, it will be allocated on the 2nd chunk, which is
    based on kernel memory or vmalloc memory (depends on
    CONFIG_NEED_PER_CPU_KM).

    Without this fix and kernel configured to use vmalloc area for
    the percpu memory, the Dom0 kernel will fail to boot with following
    errors.

    [ 0.466172] Xen: initializing cpu0
    [ 0.469601] ------------[ cut here ]------------
    [ 0.474295] WARNING: CPU: 0 PID: 1 at arch/arm64/xen/../../arm/xen/enlighten.c:153 xen_starting_cpu+0x160/0x180
    [ 0.484435] Modules linked in:
    [ 0.487565] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4+ #4
    [ 0.493895] Hardware name: Socionext Developer Box (DT)
    [ 0.499194] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--)
    [ 0.504836] pc : xen_starting_cpu+0x160/0x180
    [ 0.509263] lr : xen_starting_cpu+0xb0/0x180
    [ 0.513599] sp : ffff8000116cbb60
    [ 0.516984] x29: ffff8000116cbb60 x28: ffff80000abec000
    [ 0.522366] x27: 0000000000000000 x26: 0000000000000000
    [ 0.527754] x25: ffff80001156c000 x24: fffffdffbfcdb600
    [ 0.533129] x23: 0000000000000000 x22: 0000000000000000
    [ 0.538511] x21: ffff8000113a99c8 x20: ffff800010fe4f68
    [ 0.543892] x19: ffff8000113a9988 x18: 0000000000000010
    [ 0.549274] x17: 0000000094fe0f81 x16: 00000000deadbeef
    [ 0.554655] x15: ffffffffffffffff x14: 0720072007200720
    [ 0.560037] x13: 0720072007200720 x12: 0720072007200720
    [ 0.565418] x11: 0720072007200720 x10: 0720072007200720
    [ 0.570801] x9 : ffff8000100fbdc0 x8 : ffff800010715208
    [ 0.576182] x7 : 0000000000000054 x6 : ffff00001b790f00
    [ 0.581564] x5 : ffff800010bbf880 x4 : 0000000000000000
    [ 0.586945] x3 : 0000000000000000 x2 : ffff80000abec000
    [ 0.592327] x1 : 000000000000002f x0 : 0000800000000000
    [ 0.597716] Call trace:
    [ 0.600232] xen_starting_cpu+0x160/0x180
    [ 0.604309] cpuhp_invoke_callback+0xac/0x640
    [ 0.608736] cpuhp_issue_call+0xf4/0x150
    [ 0.612728] __cpuhp_setup_state_cpuslocked+0x128/0x2c8
    [ 0.618030] __cpuhp_setup_state+0x84/0xf8
    [ 0.622192] xen_guest_init+0x324/0x364
    [ 0.626097] do_one_initcall+0x54/0x250
    [ 0.630003] kernel_init_freeable+0x12c/0x2c8
    [ 0.634428] kernel_init+0x1c/0x128
    [ 0.637988] ret_from_fork+0x10/0x18
    [ 0.641635] ---[ end trace d95b5309a33f8b27 ]---
    [ 0.646337] ------------[ cut here ]------------
    [ 0.651005] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:158!
    [ 0.657697] Internal error: Oops - BUG: 0 [#1] SMP
    [ 0.662548] Modules linked in:
    [ 0.665676] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 5.9.0-rc4+ #4
    [ 0.673398] Hardware name: Socionext Developer Box (DT)
    [ 0.678695] pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--)
    [ 0.684338] pc : xen_starting_cpu+0x178/0x180
    [ 0.688765] lr : xen_starting_cpu+0x144/0x180
    [ 0.693188] sp : ffff8000116cbb60
    [ 0.696573] x29: ffff8000116cbb60 x28: ffff80000abec000
    [ 0.701955] x27: 0000000000000000 x26: 0000000000000000
    [ 0.707344] x25: ffff80001156c000 x24: fffffdffbfcdb600
    [ 0.712718] x23: 0000000000000000 x22: 0000000000000000
    [ 0.718107] x21: ffff8000113a99c8 x20: ffff800010fe4f68
    [ 0.723481] x19: ffff8000113a9988 x18: 0000000000000010
    [ 0.728863] x17: 0000000094fe0f81 x16: 00000000deadbeef
    [ 0.734245] x15: ffffffffffffffff x14: 0720072007200720
    [ 0.739626] x13: 0720072007200720 x12: 0720072007200720
    [ 0.745008] x11: 0720072007200720 x10: 0720072007200720
    [ 0.750390] x9 : ffff8000100fbdc0 x8 : ffff800010715208
    [ 0.755771] x7 : 0000000000000054 x6 : ffff00001b790f00
    [ 0.761153] x5 : ffff800010bbf880 x4 : 0000000000000000
    [ 0.766534] x3 : 0000000000000000 x2 : 00000000deadbeef
    [ 0.771916] x1 : 00000000deadbeef x0 : ffffffffffffffea
    [ 0.777304] Call trace:
    [ 0.779819] xen_starting_cpu+0x178/0x180
    [ 0.783898] cpuhp_invoke_callback+0xac/0x640
    [ 0.788325] cpuhp_issue_call+0xf4/0x150
    [ 0.792317] __cpuhp_setup_state_cpuslocked+0x128/0x2c8
    [ 0.797619] __cpuhp_setup_state+0x84/0xf8
    [ 0.801779] xen_guest_init+0x324/0x364
    [ 0.805683] do_one_initcall+0x54/0x250
    [ 0.809590] kernel_init_freeable+0x12c/0x2c8
    [ 0.814016] kernel_init+0x1c/0x128
    [ 0.817583] ret_from_fork+0x10/0x18
    [ 0.821226] Code: d0006980 f9427c00 cb000300 17ffffea (d4210000)
    [ 0.827415] ---[ end trace d95b5309a33f8b28 ]---
    [ 0.832076] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
    [ 0.839815] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

    Signed-off-by: Masami Hiramatsu
    Reviewed-by: Stefano Stabellini
    Link: https://lore.kernel.org/r/160196697165.60224.17470743378683334995.stgit@devnote2
    Signed-off-by: Juergen Gross

    Masami Hiramatsu
     

07 Sep, 2020

1 commit

  • Pull xen updates from Juergen Gross:
    "A small series for fixing a problem with Xen PVH guests when running
    as backends (e.g. as dom0).

    Mapping other guests' memory is now working via ZONE_DEVICE, thus not
    requiring to abuse the memory hotplug functionality for that purpose"

    * tag 'for-linus-5.9-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
    xen: add helpers to allocate unpopulated memory
    memremap: rename MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC
    xen/balloon: add header guard

    Linus Torvalds
     

04 Sep, 2020

2 commits

  • To be used in order to create foreign mappings. This is based on the
    ZONE_DEVICE facility which is used by persistent memory devices in
    order to create struct pages and kernel virtual mappings for the IOMEM
    areas of such devices. Note that on kernels without support for
    ZONE_DEVICE Xen will fallback to use ballooned pages in order to
    create foreign mappings.

    The newly added helpers use the same parameters as the existing
    {alloc/free}_xenballooned_pages functions, which allows for in-place
    replacement of the callers. Once a memory region has been added to be
    used as scratch mapping space it will no longer be released, and pages
    returned are kept in a linked list. This allows to have a buffer of
    pages and prevents resorting to frequent additions and removals of
    regions.

    If enabled (because ZONE_DEVICE is supported) the usage of the new
    functionality untangles Xen balloon and RAM hotplug from the usage of
    unpopulated physical memory ranges to map foreign pages, which is the
    correct thing to do in order to avoid mappings of foreign pages depend
    on memory hotplug.

    Note the driver is currently not enabled on Arm platforms because it
    would interfere with the identity mapping required on some platforms.

    Signed-off-by: Roger Pau Monné
    Reviewed-by: Juergen Gross
    Link: https://lore.kernel.org/r/20200901083326.21264-4-roger.pau@citrix.com
    Signed-off-by: Juergen Gross

    Roger Pau Monne
     
  • In order to protect against the header being included multiple times
    on the same compilation unit.

    Signed-off-by: Roger Pau Monné
    Reviewed-by: Boris Ostrovsky
    Link: https://lore.kernel.org/r/20200901083326.21264-2-roger.pau@citrix.com
    Signed-off-by: Juergen Gross

    Roger Pau Monne
     

30 Aug, 2020

1 commit

  • Pull xen fixes from Juergen Gross:
    "Two fixes for Xen: one needed for ongoing work to support virtio with
    Xen, and one for a corner case in IRQ handling with Xen"

    * tag 'for-linus-5.9-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
    arm/xen: Add misuse warning to virt_to_gfn
    xen/xenbus: Fix granting of vmalloc'd memory
    XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.

    Linus Torvalds
     

27 Aug, 2020

1 commit

  • As virt_to_gfn uses virt_to_phys, it will return invalid addresses when
    used with vmalloc'd addresses. This patch introduces a warning, when
    virt_to_gfn is used in this way.

    Signed-off-by: Simon Leiner
    Reviewed-by: Stefano Stabellini
    Link: https://lore.kernel.org/r/20200825093153.35500-2-simon@leiner.me
    Signed-off-by: Juergen Gross

    Simon Leiner
     

15 Aug, 2020

1 commit

  • Pull more xen updates from Juergen Gross:

    - Remove support for running as 32-bit Xen PV-guest.

    32-bit PV guests are rarely used, are lacking security fixes for
    Meltdown, and can be easily replaced by PVH mode. Another series for
    doing more cleanup will follow soon (removal of 32-bit-only pvops
    functionality).

    - Fixes and additional features for the Xen display frontend driver.

    * tag 'for-linus-5.9-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
    drm/xen-front: Pass dumb buffer data offset to the backend
    xen: Sync up with the canonical protocol definition in Xen
    drm/xen-front: Add YUYV to supported formats
    drm/xen-front: Fix misused IS_ERR_OR_NULL checks
    xen/gntdev: Fix dmabuf import with non-zero sgt offset
    x86/xen: drop tests for highmem in pv code
    x86/xen: eliminate xen-asm_64.S
    x86/xen: remove 32-bit Xen PV guest support

    Linus Torvalds
     

13 Aug, 2020

1 commit

  • This is the sync up with the canonical definition of the
    display protocol in Xen.

    1. Add protocol version as an integer

    Version string, which is in fact an integer, is hard to handle in the
    code that supports different protocol versions. To simplify that
    also add the version as an integer.

    2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE

    There are cases when display data buffer is created with non-zero
    offset to the data start. Handle such cases and provide that offset
    while creating a display buffer.

    3. Add XENDISPL_OP_GET_EDID command

    Add an optional request for reading Extended Display Identification
    Data (EDID) structure which allows better configuration of the
    display connectors over the configuration set in XenStore.
    With this change connectors may have multiple resolutions defined
    with respect to detailed timing definitions and additional properties
    normally provided by displays.

    If this request is not supported by the backend then visible area
    is defined by the relevant XenStore's "resolution" property.

    If backend provides extended display identification data (EDID) with
    XENDISPL_OP_GET_EDID request then EDID values must take precedence
    over the resolutions defined in XenStore.

    4. Bump protocol version to 2.

    Signed-off-by: Oleksandr Andrushchenko
    Reviewed-by: Juergen Gross
    Link: https://lore.kernel.org/r/20200813062113.11030-5-andr2000@gmail.com
    Signed-off-by: Juergen Gross

    Oleksandr Andrushchenko
     

08 Aug, 2020

1 commit

  • Pull xen updates from Juergen Gross:

    - two trivial comment fixes

    - a small series for the Xen balloon driver fixing some issues

    - a series of the Xen privcmd driver targeting elimination of using
    get_user_pages*() in this driver

    - a series for the Xen swiotlb driver cleaning it up and adding support
    for letting the kernel run as dom0 on Rpi4

    * tag 'for-linus-5.9-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
    xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint
    xen/arm: introduce phys/dma translations in xen_dma_sync_for_*
    swiotlb-xen: introduce phys_to_dma/dma_to_phys translations
    swiotlb-xen: remove XEN_PFN_PHYS
    swiotlb-xen: add struct device * parameter to is_xen_swiotlb_buffer
    swiotlb-xen: add struct device * parameter to xen_dma_sync_for_device
    swiotlb-xen: add struct device * parameter to xen_dma_sync_for_cpu
    swiotlb-xen: add struct device * parameter to xen_bus_to_phys
    swiotlb-xen: add struct device * parameter to xen_phys_to_bus
    swiotlb-xen: remove start_dma_addr
    swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses
    Revert "xen/balloon: Fix crash when ballooning on x86 32 bit PAE"
    xen/balloon: make the balloon wait interruptible
    xen/balloon: fix accounting in alloc_xenballooned_pages error path
    xen: hypercall.h: fix duplicated word
    xen/gntdev: gntdev.h: drop a duplicated word
    xen/privcmd: Convert get_user_pages*() to pin_user_pages*()
    xen/privcmd: Mark pages as dirty
    xen/privcmd: Corrected error handling path

    Linus Torvalds
     

04 Aug, 2020

4 commits

  • xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
    getting called passing dma addresses. On some platforms dma addresses
    could be different from physical addresses. Before doing any operations
    on these addresses we need to convert them back to physical addresses
    using dma_to_phys.

    Move the arch_sync_dma_for_cpu and arch_sync_dma_for_device calls from
    xen_dma_sync_for_cpu/device to swiotlb-xen.c, and add a call dma_to_phys
    to do address translations there.

    dma_cache_maint is fixed by the next patch.

    Signed-off-by: Stefano Stabellini
    Tested-by: Corey Minyard
    Tested-by: Roman Shaposhnik
    Acked-by: Juergen Gross
    Link: https://lore.kernel.org/r/20200710223427.6897-10-sstabellini@kernel.org
    Signed-off-by: Juergen Gross

    Stefano Stabellini
     
  • XEN_PFN_PHYS is only used in one place in swiotlb-xen making things more
    complex than need to be.

    Remove the definition of XEN_PFN_PHYS and open code the cast in the one
    place where it is needed.

    Signed-off-by: Stefano Stabellini
    Reviewed-by: Juergen Gross
    Link: https://lore.kernel.org/r/20200710223427.6897-8-sstabellini@kernel.org
    Signed-off-by: Juergen Gross

    Stefano Stabellini
     
  • No functional changes. The parameter is unused in this patch but will be
    used by next patches.

    Signed-off-by: Stefano Stabellini
    Reviewed-by: Boris Ostrovsky
    Tested-by: Corey Minyard
    Tested-by: Roman Shaposhnik
    Link: https://lore.kernel.org/r/20200710223427.6897-6-sstabellini@kernel.org
    Signed-off-by: Juergen Gross

    Stefano Stabellini
     
  • No functional changes. The parameter is unused in this patch but will be
    used by next patches.

    Signed-off-by: Stefano Stabellini
    Reviewed-by: Boris Ostrovsky
    Tested-by: Corey Minyard
    Tested-by: Roman Shaposhnik
    Link: https://lore.kernel.org/r/20200710223427.6897-5-sstabellini@kernel.org
    Signed-off-by: Juergen Gross

    Stefano Stabellini
     

02 Jul, 2020

1 commit

  • The patch adds a new extra type to be able to diffirentiate
    between RX responses on xen-netfront side with the adjusted offset
    required for XDP processing.

    The offset value from a guest is passed via xenstore.

    Signed-off-by: Denis Kirjanov
    Signed-off-by: David S. Miller

    Denis Kirjanov
     

11 Jun, 2020

3 commits

  • Kbuild test robot reports the following problem on ARM:

    for 'xen_setup_callback_vector' [-Wmissing-prototypes]
    1664 | void xen_setup_callback_vector(void) {}
    | ^~~~~~~~~~~~~~~~~~~~~~~~~

    The problem is that xen_setup_callback_vector is a x86 only thing, its
    definition is present in arch/x86/xen/xen-ops.h but not on ARM. In
    events_base.c there is a stub for !CONFIG_XEN_PVHVM but it is not declared
    as 'static'.

    On x86 the situation is hardly better: drivers/xen/events/events_base.c
    doesn't include 'xen-ops.h' from arch/x86/xen/, it includes its namesake
    from include/xen/ which also results in a 'no previous prototype' warning.

    Currently, xen_setup_callback_vector() has two call sites: one in
    drivers/xen/events_base.c and another in arch/x86/xen/suspend_hvm.c. The
    former is placed under #ifdef CONFIG_X86 and the later is only compiled
    in when CONFIG_XEN_PVHVM.

    Resolve the issue by moving xen_setup_callback_vector() declaration to
    arch neutral 'include/xen/hvm.h' as the implementation lives in arch
    neutral drivers/xen/events/events_base.c.

    Reported-by: kbuild test robot
    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: Thomas Gleixner
    Reviewed-by: Juergen Gross
    Link: https://lkml.kernel.org/r/20200520161600.361895-1-vkuznets@redhat.com

    Vitaly Kuznetsov
     
  • Convert the last oldstyle defined vector to IDTENTRY_SYSVEC:

    - Implement the C entry point with DEFINE_IDTENTRY_SYSVEC
    - Emit the ASM stub with DECLARE_IDTENTRY_SYSVEC
    - Remove the ASM idtentries in 64-bit
    - Remove the BUILD_INTERRUPT entries in 32-bit
    - Remove the old prototypes

    Fixup the related XEN code by providing the primary C entry point in x86 to
    avoid cluttering the generic code with X86'isms.

    No functional change.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Acked-by: Andy Lutomirski
    Link: https://lore.kernel.org/r/20200521202119.741950104@linutronix.de

    Thomas Gleixner
     
  • Convert the XEN/PV hypercall to IDTENTRY:

    - Emit the ASM stub with DECLARE_IDTENTRY
    - Remove the ASM idtentry in 64-bit
    - Remove the open coded ASM entry code in 32-bit
    - Remove the old prototypes

    The handler stubs need to stay in ASM code as they need corner case handling
    and adjustment of the stack pointer.

    Provide a new C function which invokes the entry/exit handling and calls
    into the XEN handler on the interrupt stack if required.

    The exit code is slightly different from the regular idtentry_exit() on
    non-preemptible kernels. If the hypercall is preemptible and need_resched()
    is set then XEN provides a preempt hypercall scheduling function.

    Move this functionality into the entry code so it can use the existing
    idtentry functionality.

    [ mingo: Build fixes. ]

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Acked-by: Andy Lutomirski
    Acked-by: Juergen Gross
    Tested-by: Juergen Gross
    Link: https://lore.kernel.org/r/20200521202118.055270078@linutronix.de

    Thomas Gleixner
     

10 Jun, 2020

2 commits

  • The replacement of with made the include
    of the latter in the middle of asm includes. Fix this up with the aid of
    the below script and manual adjustments here and there.

    import sys
    import re

    if len(sys.argv) is not 3:
    print "USAGE: %s " % (sys.argv[0])
    sys.exit(1)

    hdr_to_move="#include " % sys.argv[2]
    moved = False
    in_hdrs = False

    with open(sys.argv[1], "r") as f:
    lines = f.readlines()
    for _line in lines:
    line = _line.rstrip('
    ')
    if line == hdr_to_move:
    continue
    if line.startswith("#include
    Cc: Geert Uytterhoeven
    Cc: Greentime Hu
    Cc: Greg Ungerer
    Cc: Guan Xuetao
    Cc: Guo Ren
    Cc: Heiko Carstens
    Cc: Helge Deller
    Cc: Ingo Molnar
    Cc: Ley Foon Tan
    Cc: Mark Salter
    Cc: Matthew Wilcox
    Cc: Matt Turner
    Cc: Max Filippov
    Cc: Michael Ellerman
    Cc: Michal Simek
    Cc: Nick Hu
    Cc: Paul Walmsley
    Cc: Richard Weinberger
    Cc: Rich Felker
    Cc: Russell King
    Cc: Stafford Horne
    Cc: Thomas Bogendoerfer
    Cc: Thomas Gleixner
    Cc: Tony Luck
    Cc: Vincent Chen
    Cc: Vineet Gupta
    Cc: Will Deacon
    Cc: Yoshinori Sato
    Link: http://lkml.kernel.org/r/20200514170327.31389-4-rppt@kernel.org
    Signed-off-by: Linus Torvalds

    Mike Rapoport
     
  • The include/linux/pgtable.h is going to be the home of generic page table
    manipulation functions.

    Start with moving asm-generic/pgtable.h to include/linux/pgtable.h and
    make the latter include asm/pgtable.h.

    Signed-off-by: Mike Rapoport
    Signed-off-by: Andrew Morton
    Cc: Arnd Bergmann
    Cc: Borislav Petkov
    Cc: Brian Cain
    Cc: Catalin Marinas
    Cc: Chris Zankel
    Cc: "David S. Miller"
    Cc: Geert Uytterhoeven
    Cc: Greentime Hu
    Cc: Greg Ungerer
    Cc: Guan Xuetao
    Cc: Guo Ren
    Cc: Heiko Carstens
    Cc: Helge Deller
    Cc: Ingo Molnar
    Cc: Ley Foon Tan
    Cc: Mark Salter
    Cc: Matthew Wilcox
    Cc: Matt Turner
    Cc: Max Filippov
    Cc: Michael Ellerman
    Cc: Michal Simek
    Cc: Nick Hu
    Cc: Paul Walmsley
    Cc: Richard Weinberger
    Cc: Rich Felker
    Cc: Russell King
    Cc: Stafford Horne
    Cc: Thomas Bogendoerfer
    Cc: Thomas Gleixner
    Cc: Tony Luck
    Cc: Vincent Chen
    Cc: Vineet Gupta
    Cc: Will Deacon
    Cc: Yoshinori Sato
    Link: http://lkml.kernel.org/r/20200514170327.31389-3-rppt@kernel.org
    Signed-off-by: Linus Torvalds

    Mike Rapoport
     

07 Apr, 2020

1 commit


30 Mar, 2020

1 commit


05 Mar, 2020

2 commits

  • Commit 060eabe8fbe726 ("xenbus/backend: Protect xenbus callback with
    lock") introduced a bug by holding a lock while calling a function
    which might schedule.

    Fix that by using a semaphore instead.

    Fixes: 060eabe8fbe726 ("xenbus/backend: Protect xenbus callback with lock")
    Signed-off-by: Juergen Gross
    Link: https://lore.kernel.org/r/20200305100323.16736-1-jgross@suse.com
    Reviewed-by: Boris Ostrovsky
    Signed-off-by: Boris Ostrovsky

    Juergen Gross
     
  • The current codebase makes use of the zero-length array language
    extension to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning
    in case the flexible array does not occur last in the structure, which
    will help us prevent some kind of undefined behavior bugs from being
    inadvertently introduced[3] to the codebase from now on.

    Also, notice that, dynamic memory allocations won't be affected by
    this change:

    "Flexible array members have incomplete type, and so the sizeof operator
    may not be applied. As a quirk of the original implementation of
    zero-length arrays, sizeof evaluates to zero."[1]

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Link: https://lore.kernel.org/r/20200226212612.GA4663@embeddedor
    Reviewed-by: Juergen Gross
    Signed-off-by: Boris Ostrovsky

    Gustavo A. R. Silva
     

06 Feb, 2020

1 commit

  • Pull xen updates from Juergen Gross:

    - fix a bug introduced in 5.5 in the Xen gntdev driver

    - fix the Xen balloon driver when running on ancient Xen versions

    - allow Xen stubdoms to control interrupt enable flags of
    passed-through PCI cards

    - release resources in Xen backends under memory pressure

    * tag 'for-linus-5.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
    xen/blkback: Consistently insert one empty line between functions
    xen/blkback: Remove unnecessary static variable name prefixes
    xen/blkback: Squeeze page pools if a memory pressure is detected
    xenbus/backend: Protect xenbus callback with lock
    xenbus/backend: Add memory pressure handler callback
    xen/gntdev: Do not use mm notifiers with autotranslating guests
    xen/balloon: Support xend-based toolstack take two
    xen-pciback: optionally allow interrupt enable flag writes

    Linus Torvalds
     

29 Jan, 2020

2 commits

  • A driver's 'reclaim_memory' callback can race with 'probe' or 'remove'
    because it will be called whenever memory pressure is detected. To
    avoid such race, this commit embeds a spinlock in each 'xenbus_device'
    and make 'xenbus' to hold the lock while the corresponded callbacks are
    running.

    Reviewed-by: Juergen Gross
    Signed-off-by: SeongJae Park
    Signed-off-by: Boris Ostrovsky

    SeongJae Park
     
  • Granting pages consumes backend system memory. In systems configured
    with insufficient spare memory for those pages, it can cause a memory
    pressure situation. However, finding the optimal amount of the spare
    memory is challenging for large systems having dynamic resource
    utilization patterns. Also, such a static configuration might lack
    flexibility.

    To mitigate such problems, this commit adds a memory reclaim callback to
    'xenbus_driver'. If a memory pressure is detected, 'xenbus' requests
    every backend driver to volunarily release its memory.

    Note that it would be able to improve the callback facility for more
    sophisticated handlings of general pressures. For example, it would be
    possible to monitor the memory consumption of each device and issue the
    release requests to only devices which causing the pressure. Also, the
    callback could be extended to handle not only memory, but general
    resources. Nevertheless, this version of the implementation defers such
    sophisticated goals as a future work.

    Reviewed-by: Juergen Gross
    Reviewed-by: Roger Pau Monné
    Signed-off-by: SeongJae Park
    Signed-off-by: Boris Ostrovsky

    SeongJae Park
     

25 Dec, 2019

1 commit


20 Dec, 2019

1 commit

  • Currently these macros are defined to re-initialize a front/back ring
    (respectively) to values read from the shared ring in such a way that any
    requests/responses that are added to the shared ring whilst the front/back
    is detached will be skipped over. This, in general, is not a desirable
    semantic since most frontend implementations will eventually block waiting
    for a response which would either never appear or never be processed.

    Since the macros are currently unused, take this opportunity to re-define
    them to re-initialize a front/back ring using specified values. This also
    allows FRONT/BACK_RING_INIT() to be re-defined in terms of
    FRONT/BACK_RING_ATTACH() using a specified value of 0.

    NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch.

    Signed-off-by: Paul Durrant
    Reviewed-by: Juergen Gross
    Signed-off-by: Juergen Gross

    Paul Durrant