On 19.11.20 13:01, Peter Zijlstra wrote:
On Thu, Nov 19, 2020 at 11:51:00AM +, Shinichiro Kawasaki wrote:
I tried Peter's patch in my test system and result looks good. The warning is
still observed with 5.10-rc4. With the patch on top of 5.10-rc4, the warning
disappeared.
The patch on
On 16.11.20 14:04, Peter Zijlstra wrote:
On Mon, Nov 16, 2020 at 12:56:32PM +0100, Jürgen Groß wrote:
static inline notrace unsigned long arch_local_save_flags(void)
{
PVOP_CALL_ARGS;
PVOP_TEST_NULL(irq.save_fl);
asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL
On 16.11.20 17:28, Andy Lutomirski wrote:
On Mon, Nov 16, 2020 at 7:23 AM Juergen Gross wrote:
USERGS_SYSRET64 is used to return from a syscall via sysret, but
a Xen PV guest will nevertheless use the iret hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the
On 16.11.20 17:12, Andy Lutomirski wrote:
On Mon, Nov 16, 2020 at 7:23 AM Juergen Gross wrote:
Xen PV guests don't use IST. For double fault interrupts switch to
the same model as NMI.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/idtentry.h | 3 +++
arch/x86/xen/enlighten_pv.c
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
On 11/11/2020 20:15, Josh Poimboeuf wrote:
On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:
On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote:
On Wed, Nov 11, 2020 at
On 15.11.20 17:05, Andy Lutomirski wrote:
On Nov 14, 2020, at 10:33 PM, Jürgen Groß wrote:
On 14.11.20 19:10, Andy Lutomirski wrote:
On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß wrote:
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
So I
On 14.11.20 19:10, Andy Lutomirski wrote:
On Sat, Nov 14, 2020 at 1:16 AM Jürgen Groß wrote:
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
So I think there is at most one of these that wants anything more
complicated than a plain
On 13.11.20 18:34, Andy Lutomirski wrote:
On Wed, Nov 11, 2020 at 12:25 PM Andrew Cooper
wrote:
On 11/11/2020 20:15, Josh Poimboeuf wrote:
On Wed, Nov 11, 2020 at 09:07:30PM +0100, Peter Zijlstra wrote:
On Wed, Nov 11, 2020 at 01:59:00PM -0600, Josh Poimboeuf wrote:
On Wed, Nov 11, 2020 at
On 07.11.20 02:11, Brian Masney wrote:
When booting a hyperthreaded system with the kernel parameter
'mitigations=auto,nosmt', the following warning occurs:
WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
unbind_from_irqhandler+0x4e/0x60
...
Hardware name: Xen
On 04.11.20 10:06, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netfront.c: In function ‘store_rxbuf’:
drivers/net/xen-netfront.c:2416:16: warning: variable ‘target’ set but not
used [-Wunused-but-set-variable]
Those two warnings are not fixed by the
On 22.10.20 12:35, Jan Beulich wrote:
On 22.10.2020 11:49, Juergen Gross wrote:
@@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
int ret = -EINVAL;
evtchn_port_t evtchn;
- if (fifo_events)
+ if (xen_fifo_events)
ret = xen_evtchn_fifo_init();
-
On 22.10.20 12:45, Peter Zijlstra wrote:
On Thu, Oct 22, 2020 at 11:24:39AM +0200, Jürgen Groß wrote:
On 09.10.20 16:42, Juergen Gross wrote:
When running in lazy TLB mode the currently active page tables might
be the ones of a previous process, e.g. when running a kernel thread.
This can
On 09.10.20 16:42, Juergen Gross wrote:
When running in lazy TLB mode the currently active page tables might
be the ones of a previous process, e.g. when running a kernel thread.
This can be problematic in case kernel code is being modified via
text_poke() in a kernel thread, and on another
On 22.10.20 09:55, Jan Beulich wrote:
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 <<
On 22.10.20 09:54, Jan Beulich wrote:
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
Rzeszutek Wilk
Cc: Jens Axboe
Cc: Boris Ostrovsky
Cc: SeongJae Park
Cc: xen-de...@lists.xenproject.org
Cc: linux-bl...@vger.kernel.org
Cc: J. Roeleveld
Cc: Jürgen Groß
---
Documentation/ABI/testing/sysfs-driver-xen-blkback | 9 +
drivers/block/xen-blkback/blkback.c| 7
Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Jens Axboe
Cc: Boris Ostrovsky
Cc: SeongJae Park
Cc: xen-de...@lists.xenproject.org
Cc: linux-bl...@vger.kernel.org
Cc: J. Roeleveld
Cc: Jürgen Groß
---
Documentation/ABI/testing/sysfs-driver-xen-blkback | 10 ++
drivers/block/xen-blkback
On 14.10.20 19:53, Jason Andryuk wrote:
Moving XEN_512GB allows it to nest under XEN_PV. That also allows
XEN_PVH to nest under XEN as a sibling to XEN_PV and XEN_PVHVM giving:
[*] Xen guest support
[*] Xen PV guest support
[*] Limit Xen pv-domain memory to 512GB
[*] Xen PV
On 12.10.20 12:13, Peter Zijlstra wrote:
On Fri, Oct 09, 2020 at 04:42:25PM +0200, Juergen Gross wrote:
When running in lazy TLB mode the currently active page tables might
be the ones of a previous process, e.g. when running a kernel thread.
This can be problematic in case kernel code is
On 30.09.20 10:52, Stefan Bader wrote:
On 29.09.20 16:05, Jürgen Groß wrote:
On 29.09.20 15:13, Stefan Bader wrote:
On 01.09.20 17:10, Greg Kroah-Hartman wrote:
From: Thomas Gleixner
commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream.
handler data is meant for interrupt handlers
On 29.09.20 15:13, Stefan Bader wrote:
On 01.09.20 17:10, Greg Kroah-Hartman wrote:
From: Thomas Gleixner
commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream.
handler data is meant for interrupt handlers and not for storing irq chip
specific information as some devices require handler
On 22.09.20 16:15, SeongJae Park wrote:
From: SeongJae Park
Commit 14e710fe7897 ("xen-blkfront: rename indirect descriptor
parameter") changed the name of the module parameter for the maximum
amount of segments in indirect requests but missed updating the
document. This commit updates the
On 22.09.20 16:15, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. It can be disabled from blkback side using a
module parameter,
On 22.09.20 16:15, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. But, there is no option to disable it. For
the reason, this commit
On 22.09.20 12:52, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overheads[1] and thus it is
required to be disabled. It can be disabled from blkback side using a
module parameter,
On 22.09.20 13:26, SeongJae Park wrote:
On Tue, 22 Sep 2020 13:12:59 +0200 "Roger Pau Monné"
wrote:
On Tue, Sep 22, 2020 at 12:52:07PM +0200, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data
On 19.09.20 05:17, Jing Xiangfeng wrote:
After commit 9f51c05dc41a ("pvcalls-front: Avoid
get_free_pages(GFP_KERNEL) under spinlock"), the variable ret is being
initialized with '-ENOMEM' that is meaningless. So remove it.
Signed-off-by: Jing Xiangfeng
Reviewed-by: Juergen Gross
Juergen
On 22.09.20 09:01, SeongJae Park wrote:
From: SeongJae Park
Persistent grants feature provides high scalability. On some small
systems, however, it could incur data copy overhead[1] and thus it is
required to be disabled. But, there is no option to disable it. For
the reason, this commit
On 08.09.20 22:10, David Hildenbrand wrote:
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc:
On 08.09.20 22:10, David Hildenbrand wrote:
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc:
On 06.09.20 19:01, Linus Torvalds wrote:
On Sat, Sep 5, 2020 at 9:44 PM Juergen Gross wrote:
It contains a small series for fixing a problem with Xen PVH guests
when running as backends (e.g. as dom0). Mapping other guests' memory
now is working via ZONE_DEVICE, thus not requiring to abuse
On 01.09.20 10:33, Roger Pau Monne wrote:
Hello,
The following series contain some fixes in order to split Xen
unpopulated memory handling from the ballooning driver using the
ZONE_DEVICE functionality, so that physical memory regions used to map
foreign pages are not tied to memory hotplug.
On 04.09.20 10:42, Roger Pau Monné wrote:
On Fri, Sep 04, 2020 at 09:00:18AM +0200, Jürgen Groß wrote:
On 03.09.20 18:38, Roger Pau Monné wrote:
On Thu, Sep 03, 2020 at 05:30:07PM +0200, Jürgen Groß wrote:
On 01.09.20 10:33, Roger Pau Monne wrote:
To be used in order to create foreign
On 03.09.20 18:38, Roger Pau Monné wrote:
On Thu, Sep 03, 2020 at 05:30:07PM +0200, Jürgen Groß wrote:
On 01.09.20 10:33, Roger Pau Monne wrote:
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
On 01.09.20 10:33, Roger Pau Monne wrote:
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
On 02.09.20 17:58, Brian Gerst wrote:
On Wed, Sep 2, 2020 at 9:38 AM Peter Zijlstra wrote:
From: Peter Zijlstra
The WARN added in commit 3c73b81a9164 ("x86/entry, selftests: Further
improve user entry sanity checks") unconditionally triggers on my IVB
machine because it does not support
On 21.08.20 12:34, David Hildenbrand wrote:
Let's reuse the new mechanism to merge system ram resources below the
root. We are the only one hotplugging system ram (e.g., DIMMs don't apply),
so this is safe to be used.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
On 01.09.20 16:45, Roger Pau Monné wrote:
On Tue, Sep 01, 2020 at 10:33:26AM +0200, Roger Pau Monne wrote:
+static int fill_list(unsigned int nr_pages)
+{
+ struct dev_pagemap *pgmap;
+ void *vaddr;
+ unsigned int i, alloc_pages = round_up(nr_pages, PAGES_PER_SECTION);
+
On 26.08.20 13:16, Thomas Gleixner wrote:
From: Thomas Gleixner
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
To achieve this XEN MSI interrupt management needs to be wrapped into
On 26.08.20 13:16, Thomas Gleixner wrote:
From: Thomas Gleixner
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
XENs MSI teardown relies on default_teardown_msi_irqs() which invokes
On 24.08.20 23:21, Thomas Gleixner wrote:
On Mon, Aug 24 2020 at 06:59, Jürgen Groß wrote:
On 21.08.20 02:24, Thomas Gleixner wrote:
+static __init void xen_setup_pci_msi(void)
+{
+ if (xen_initial_domain()) {
+ x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs
On 24.08.20 17:58, Andrew Cooper wrote:
On 24/08/2020 16:21, pet...@infradead.org wrote:
On Mon, Aug 24, 2020 at 03:22:06PM +0100, Andrew Cooper wrote:
On 24/08/2020 11:14, pet...@infradead.org wrote:
The WARN added in commit 3c73b81a9164 ("x86/entry, selftests: Further
improve user entry
On 21.08.20 02:24, Thomas Gleixner wrote:
To allow utilizing the irq domain pointer in struct device it is necessary
to make XEN/MSI irq domain compatible.
While the right solution would be to truly convert XEN to irq domains, this
is an exercise which is not possible for mere mortals with
On 21.08.20 02:24, Thomas Gleixner wrote:
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
XENs MSI teardown relies on default_teardown_msi_irqs() which invokes
On 21.08.20 02:24, Thomas Gleixner wrote:
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
To achieve this XEN MSI interrupt management needs to be wrapped into an
irq domain.
Move
On 21.08.20 02:24, Thomas Gleixner wrote:
The only user is in the same file and the name is too generic because this
function is only ever used for HVM domains.
Signed-off-by: Thomas Gleixner
Cc: Konrad Rzeszutek Wilk
Cc:linux-...@vger.kernel.org
Cc:xen-de...@lists.xenproject.org
Cc: Juergen
On 21.08.20 02:24, Thomas Gleixner wrote:
First of all, sorry for the horrible long Cc list, which was
unfortunately unavoidable as this touches the world and some more.
This patch series aims to provide a base to support device MSI (non
PCI based) in a halfways architecture independent way.
On 20.08.20 16:40, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 19, 2020 at 08:09:11PM -0700, Randy Dunlap wrote:
Hi Konrad,
Hey Randy,
I believe Juergen is picking this up.
Yes, have queued it for rc2.
Juergen
ping.
I am still seeing this build error. It looks like this is
in your
On 14.08.20 15:35, Roger Pau Monné wrote:
On Fri, Aug 14, 2020 at 02:54:38PM +0200, Jürgen Groß wrote:
On 14.08.20 14:47, Roger Pau Monné wrote:
On Fri, Aug 14, 2020 at 12:27:32PM +0200, Jürgen Groß wrote:
On 14.08.20 11:56, Roger Pau Monné wrote:
On Fri, Aug 14, 2020 at 08:29:20AM +0100
On 14.08.20 14:47, Roger Pau Monné wrote:
On Fri, Aug 14, 2020 at 12:27:32PM +0200, Jürgen Groß wrote:
On 14.08.20 11:56, Roger Pau Monné wrote:
On Fri, Aug 14, 2020 at 08:29:20AM +0100, Christoph Hellwig wrote:
On Thu, Aug 13, 2020 at 09:54:20AM +0200, Roger Pau Monn?? wrote:
On Thu, Aug 13
On 14.08.20 11:56, Roger Pau Monné wrote:
On Fri, Aug 14, 2020 at 08:29:20AM +0100, Christoph Hellwig wrote:
On Thu, Aug 13, 2020 at 09:54:20AM +0200, Roger Pau Monn?? wrote:
On Thu, Aug 13, 2020 at 08:33:37AM +0100, Christoph Hellwig wrote:
On Tue, Aug 11, 2020 at 11:44:47AM +0200, Roger Pau
On 13.08.20 17:10, Oleksandr Andrushchenko wrote:
On 8/13/20 6:02 PM, Jürgen Groß wrote:
On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Series pushed to:
xen/tip.git for-linus-5.9
The top patch has strange title though:
"Subject: [PATCH v2 5/5] dr
On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Series pushed to:
xen/tip.git for-linus-5.9
Juergen
On 13.08.20 08:32, Oleksandr Andrushchenko wrote:
Juergen, Boris,
can we please merge these via Xen Linux tree as I have collected enough Ack/R-b?
The series has DRM patches, but those anyway are Xen related, so I think
this should be fine from DRI point of view.
Yes, fine with me.
On 11.08.20 11:44, Roger Pau Monne wrote:
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
On 11.08.20 10:12, Peter Zijlstra wrote:
On Tue, Aug 11, 2020 at 09:57:55AM +0200, Jürgen Groß wrote:
On 11.08.20 09:41, Peter Zijlstra wrote:
On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
My hypothesis here is simply that kvm_wait() may be called in a place
where we get
On 11.08.20 10:12, Peter Zijlstra wrote:
On Tue, Aug 11, 2020 at 09:57:55AM +0200, Jürgen Groß wrote:
On 11.08.20 09:41, Peter Zijlstra wrote:
On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
My hypothesis here is simply that kvm_wait() may be called in a place
where we get
On 11.08.20 09:41, Peter Zijlstra wrote:
On Fri, Aug 07, 2020 at 05:19:03PM +0200, Marco Elver wrote:
My hypothesis here is simply that kvm_wait() may be called in a place
where we get the same case I mentioned to Peter,
raw_local_irq_save(); /* or other IRQs off without tracing */
On 11.08.20 09:00, Marco Elver wrote:
On Fri, 7 Aug 2020 at 17:19, Marco Elver wrote:
On Fri, Aug 07, 2020 at 02:08PM +0200, Marco Elver wrote:
On Fri, 7 Aug 2020 at 14:04, Jürgen Groß wrote:
On 07.08.20 13:38, Marco Elver wrote:
On Fri, Aug 07, 2020 at 12:35PM +0200, Jürgen Groß wrote
On 10.08.20 18:53, Boris Ostrovsky wrote:
On 8/10/20 12:39 AM, Jürgen Groß wrote:
On 09.08.20 04:34, Boris Ostrovsky wrote:
On 8/7/20 4:38 AM, Juergen Gross wrote:
@@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
{
pteval_t ret;
- if (sizeof(pteval_t) > sizeof(l
On 09.08.20 04:34, Boris Ostrovsky wrote:
On 8/7/20 4:38 AM, Juergen Gross wrote:
@@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
{
pteval_t ret;
- if (sizeof(pteval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32);
-
On 09.08.20 04:04, Boris Ostrovsky wrote:
On 8/7/20 4:38 AM, Juergen Gross wrote:
With 32-bit pv-guest support removed xen-asm_64.S can be merged with
xen-asm.S
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
except for
diff --git a/arch/x86/xen/xen-asm.S
On 09.08.20 04:22, Boris Ostrovsky wrote:
On 8/7/20 4:38 AM, Juergen Gross wrote:
With support for 32-bit pv guests gone pure pv-code no longer needs to
test for highmem. Dropping those tests removes the need for flushing
in some places.
Signed-off-by: Juergen Gross
Reviewed-by: Boris
On 09.08.20 04:01, Boris Ostrovsky wrote:
On 8/7/20 4:38 AM, Juergen Gross wrote:
void __init xen_reserve_top(void)
{
-#ifdef CONFIG_X86_32
- unsigned long top = HYPERVISOR_VIRT_START;
- struct xen_platform_parameters pp;
-
- if
On 07.08.20 13:38, Marco Elver wrote:
On Fri, Aug 07, 2020 at 12:35PM +0200, Jürgen Groß wrote:
On 07.08.20 11:50, Marco Elver wrote:
On Fri, Aug 07, 2020 at 11:24AM +0200, Jürgen Groß wrote:
On 07.08.20 11:01, Marco Elver wrote:
On Thu, 6 Aug 2020 at 18:06, Marco Elver wrote:
On Thu, 6
On 07.08.20 11:50, Marco Elver wrote:
On Fri, Aug 07, 2020 at 11:24AM +0200, Jürgen Groß wrote:
On 07.08.20 11:01, Marco Elver wrote:
On Thu, 6 Aug 2020 at 18:06, Marco Elver wrote:
On Thu, 6 Aug 2020 at 15:17, Marco Elver wrote:
On Thu, Aug 06, 2020 at 01:32PM +0200, pet...@infradead.org
On 07.08.20 11:39, pet...@infradead.org wrote:
On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote:
-# else
- const unsigned char cpu_iret[1];
-# endif
};
static const struct patch_xxl patch_data_xxl = {
@@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl
On 07.08.20 11:01, Marco Elver wrote:
On Thu, 6 Aug 2020 at 18:06, Marco Elver wrote:
On Thu, 6 Aug 2020 at 15:17, Marco Elver wrote:
On Thu, Aug 06, 2020 at 01:32PM +0200, pet...@infradead.org wrote:
On Thu, Aug 06, 2020 at 09:47:23AM +0200, Marco Elver wrote:
Testing my hypothesis that
On 05.08.20 16:12, pet...@infradead.org wrote:
On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote:
On Wed, Aug 05, 2020 at 03:42PM +0200, pet...@infradead.org wrote:
Shouldn't we __always_inline those? They're going to be really small.
I can send a v2, and you can choose. For
On 04.08.20 08:35, Oleksandr Andrushchenko wrote:
On 8/4/20 9:12 AM, Jürgen Groß wrote:
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
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
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
On 11.07.20 00:34, Stefano Stabellini wrote:
Hi all,
This series is a collection of fixes to get Linux running on the RPi4 as
dom0. Conceptually there are only two significant changes:
- make sure not to call virt_to_page on vmalloc virt addresses (patch
#1)
- use phys_to_dma and
On 11.07.20 00:34, Stefano Stabellini wrote:
From: Stefano Stabellini
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
On 11.07.20 00:34, Stefano Stabellini wrote:
From: 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
On 11.07.20 00:34, Stefano Stabellini wrote:
From: Stefano Stabellini
With some devices physical addresses are different than dma addresses.
To be able to deal with these cases, we need to call phys_to_dma on
physical addresses (including machine addresses in Xen terminology)
before returning
On 27.07.20 11:13, Roger Pau Monne wrote:
This reverts commit dfd74a1edfaba5864276a2859190a8d242d18952.
This has been fixed by commit dca4436d1cf9e0d237c which added the out
of bounds check to __add_memory, so that trying to add blocks past
MAX_PHYSMEM_BITS will fail.
Note the check in the Xen
On 27.07.20 11:13, Roger Pau Monne wrote:
target_unpopulated is incremented with nr_pages at the start of the
function, but the call to free_xenballooned_pages will only subtract
pgno number of pages, and thus the rest need to be subtracted before
returning or else accounting will be skewed.
On 27.07.20 11:13, Roger Pau Monne wrote:
So it can be killed, or else processes can get hung indefinitely
waiting for balloon pages.
Signed-off-by: Roger Pau Monné
Reviewed-by: Juergen Gross
Cc: sta...@vger.kernel.org
Pushed to: xen/tip.git for-linus-5.9
Juergen
On 26.07.20 02:17, Randy Dunlap wrote:
Change the repeated word "as" to "as a".
Signed-off-by: Randy Dunlap
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-de...@lists.xenproject.org
Pushed to: xen/tip.git for-linus-5.9
Juergen
On 19.07.20 02:33, Randy Dunlap wrote:
Drop the repeated word "of" in a comment.
Signed-off-by: Randy Dunlap
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-de...@lists.xenproject.org
Pushed to xen/tip.git for-linus-5.9
Juergen
On 12.07.20 05:39, Souptick Joarder wrote:
This series contains few clean up, minor bug fixes and
Convert get_user_pages() to pin_user_pages().
I'm compile tested this, but unable to run-time test,
so any testing help is much appriciated.
v2:
Addressed few review comments and compile
On 28.07.20 09:10, Souptick Joarder wrote:
Hi Boris,
On Sun, Jul 12, 2020 at 9:01 AM Souptick Joarder wrote:
This series contains few clean up, minor bug fixes and
Convert get_user_pages() to pin_user_pages().
I'm compile tested this, but unable to run-time test,
so any testing help is much
On 27.07.20 11:13, Roger Pau Monne wrote:
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
On 26.07.20 02:17, Randy Dunlap wrote:
Change the repeated word "as" to "as a".
Signed-off-by: Randy Dunlap
Reviewed-by: Juergen Gross
Juergen
On 24.07.20 14:42, Roger Pau Monne wrote:
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
On 24.07.20 14:42, Roger Pau Monne wrote:
This reverts commit dfd74a1edfaba5864276a2859190a8d242d18952.
This has been fixed by commit dca4436d1cf9e0d237c which added the out
of bounds check to __add_memory, so that trying to add blocks past
MAX_PHYSMEM_BITS will fail.
Note the check in the Xen
On 24.07.20 14:42, Roger Pau Monne wrote:
So it can be killed, or else processes can get hung indefinitely
waiting for balloon pages.
Signed-off-by: Roger Pau Monné
Reviewed-by: Juergen Gross
Juergen
On 24.07.20 14:42, Roger Pau Monne wrote:
target_unpopulated is incremented with nr_pages at the start of the
function, but the call to free_xenballooned_pages will only subtract
pgno number of pages, and thus the rest need to be subtracted before
returning or else accounting will be skewed.
On 23.07.20 15:59, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 03:22:49PM +0200, David Hildenbrand wrote:
On 23.07.20 14:23, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 01:37:03PM +0200, David Hildenbrand wrote:
On 23.07.20 10:45, Roger Pau Monne wrote:
Add an extra option to
On 23.07.20 15:47, David Hildenbrand wrote:
On 23.07.20 15:22, David Hildenbrand wrote:
On 23.07.20 14:23, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 01:37:03PM +0200, David Hildenbrand wrote:
On 23.07.20 10:45, Roger Pau Monne wrote:
Add an extra option to add_memory_resource that
On 23.07.20 15:39, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 03:20:55PM +0200, Jürgen Groß wrote:
On 23.07.20 15:08, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 02:28:13PM +0200, Jürgen Groß wrote:
On 23.07.20 14:23, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 01:37:03PM +0200
On 23.07.20 15:08, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 02:28:13PM +0200, Jürgen Groß wrote:
On 23.07.20 14:23, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 01:37:03PM +0200, David Hildenbrand wrote:
On 23.07.20 10:45, Roger Pau Monne wrote:
Add an extra option
On 23.07.20 14:23, Roger Pau Monné wrote:
On Thu, Jul 23, 2020 at 01:37:03PM +0200, David Hildenbrand wrote:
On 23.07.20 10:45, Roger Pau Monne wrote:
Add an extra option to add_memory_resource that overrides the memory
hotplug online behavior in order to force onlining of memory from
On 21.07.20 12:02, Colin King wrote:
From: Colin Ian King
The pointer bitmap is being initialized with a plain integer 0,
fix this by initializing it with a NULL instead.
Cleans up sparse warning:
arch/x86/xen/enlighten_pv.c:876:27: warning: Using plain integer
as NULL pointer
Signed-off-by:
On 19.07.20 02:33, Randy Dunlap wrote:
Drop the repeated word "of" in a comment.
Signed-off-by: Randy Dunlap
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: xen-de...@lists.xenproject.org
Reviewed-by: Juergen Gross
Juergen
On 18.07.20 01:53, Andy Lutomirski wrote:
tss_invalidate_io_bitmap() wasn't wired up properly through the pvop
machinery, so the TSS and Xen's io bitmap would get out of sync
whenever disabling a valid io bitmap.
Add a new pvop for tss_invalidate_io_bitmap() to fix it.
This is XSA-329.
Cc:
On 10.07.20 15:27, Ard Biesheuvel wrote:
On Fri, 10 Jul 2020 at 13:17, Bartlomiej Zolnierkiewicz
wrote:
[ added EFI Maintainer & ML to Cc: ]
Hi,
On 7/9/20 11:17 AM, Jürgen Groß wrote:
On 28.06.20 10:50, Jürgen Groß wrote:
Ping?
On 10.06.20 16:10, Juergen Gross wrote:
efifb_p
On 28.06.20 10:50, Jürgen Groß wrote:
Ping?
On 10.06.20 16:10, Juergen Gross wrote:
efifb_probe() will issue an error message in case the kernel is booted
as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
101 - 200 of 263 matches
Mail list logo
