flight 154718 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154718/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 154644 pass in 154718
test-armhf-armhf-xl-rtds 16 guest-s
On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
>
> > this series removes alloc_vm_area, which was left over from the big
> > vmalloc interface rework. It is a rather arkane interface, basicaly
> > the equivalent of get
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework. It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area. It was
branch xen-4.13-testing
xenbranch xen-4.13-testing
job test-xtf-amd64-amd64-4
testid xtf/test-hvm64-xsa-221
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenb
On Fri, Sep 25 2020 at 17:49, Peter Zijlstra wrote:
> Here it looks like this:
>
> [1.830276] BUG: kernel NULL pointer dereference, address:
> [1.838043] #PF: supervisor instruction fetch in kernel mode
> [1.844357] #PF: error_code(0x0010) - not-present page
> [1.85
branch xen-4.12-testing
xenbranch xen-4.12-testing
job test-xtf-amd64-amd64-4
testid xtf/test-hvm64-xsa-221
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenb
flight 154795 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154795/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On Fri, 2020-09-25 at 20:21 +, Volodymyr Babchuk wrote:
> Hi Dario,
>
Hi! :-)
> Dario Faggioli writes:
> > And what about the cases where schedule() does return?
>
> Can it return on x86? I want to test this case, but how force it?
> Null
> scheduler, perhaps?
>
> > Are these also fine beca
branch xen-unstable
xenbranch xen-unstable
job test-xtf-amd64-amd64-4
testid xtf/test-hvm64-xsa-221
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xen
Hi Dario,
Dario Faggioli writes:
> On Thu, 2020-09-24 at 18:08 +, Volodymyr Babchuk wrote:
>> So, as I see this, functions are called in the following way (on
>> x86):
>>
>> 1. do_softirq() calls vcpu_begin_hyp_task() and then executes
>> __do_softirq()
>>
>> 2. __do_softirq() does diffe
On 9/25/20 3:04 PM, Anchal Agarwal wrote:
> On Tue, Sep 22, 2020 at 11:17:36PM +, Anchal Agarwal wrote:
>> On Tue, Sep 22, 2020 at 12:18:05PM -0400, boris.ostrov...@oracle.com wrote:
>>> CAUTION: This email originated from outside of the organization. Do not
>>> click links or open attachmen
On Tue, Sep 22, 2020 at 11:17:36PM +, Anchal Agarwal wrote:
> On Tue, Sep 22, 2020 at 12:18:05PM -0400, boris.ostrov...@oracle.com wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
On Fri, Sep 25, 2020 at 12:02 PM Julien Grall wrote:
>
> Hi Jan,
>
> On 25/09/2020 16:36, Jan Beulich wrote:
> > On 25.09.2020 16:33, Julien Grall wrote:
> >> On 25/09/2020 14:58, Jan Beulich wrote:
> >>> On 25.09.2020 15:16, Julien Grall wrote:
> Fair enough. I would still like to consider a
On Thu, 2020-09-24 at 18:08 +, Volodymyr Babchuk wrote:
> So, as I see this, functions are called in the following way (on
> x86):
>
> 1. do_softirq() calls vcpu_begin_hyp_task() and then executes
> __do_softirq()
>
> 2. __do_softirq() does different jobs and eventually calls schedule()
>
>
On 21/09/2020 14:58, Jan Beulich wrote:
> On 21.09.2020 15:04, Andrew Cooper wrote:
>> MFENCE is overly heavyweight for SMP semantics on WB memory, because it also
>> orders weaker cached writes, and flushes the WC buffers.
>>
>> This technique was used as an optimisation in Java[1], and later adop
On 25.09.2020 18:00, Julien Grall wrote:
> On 25/09/2020 16:36, Jan Beulich wrote:
>> Plus, as said, the minimal change of making Flask
>> avoid xmalloc() when IRQs are off is a change that ought to be made
>> anyway imo, in order to favor proper functioning over performance.
> If there are other u
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_vm_area prefeaults the
vmalloc area PTEs, which doe
On Fri, Sep 25, 2020 at 03:08:59PM +0100, Matthew Auld wrote:
> > + i = 0;
> > + for_each_sgt_page(page, iter, obj->mm.pages)
> > + pages[i++] = page;
> > + vaddr = vmap(pages, n_pages, 0, pgprot);
> > + if (pages != stack)
> > + kvfree(pages);
>
Hi Jan,
On 25/09/2020 16:36, Jan Beulich wrote:
On 25.09.2020 16:33, Julien Grall wrote:
On 25/09/2020 14:58, Jan Beulich wrote:
On 25.09.2020 15:16, Julien Grall wrote:
Fair enough. I would still like to consider a way where we could avoid
to hack xsm_* because we have the interrupts disable
On 22.09.2020 20:24, Andrew Cooper wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1007,6 +1007,26 @@ static long xatp_permission_check(struct domain *d,
> unsigned int space)
> return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> }
>
> +/*
> + * Return 0 on an
wapper/0 Tainted: G I
>5.9.0-rc6-next-20200925 #2
> [8.503987][T0] Hardware name: HPE ProLiant DL560 Gen10/ProLiant DL560
> Gen10, BIOS U34 11/13/2019
> [8.513238][T0] RIP: 0010:0x0
> [8.516562][T0] Code: Bad RIP v
Here it looks like t
On Fri, Sep 25, 2020 at 08:49:01AM +0200, Jan Beulich wrote:
> I don't think so, no - new ports will similarly have asm-/config.h,
> and there shouldn't be a requirement to "git add -f" them at that point.
> The role of such named files really is too different to have such a top
> level entry imo.
On 25.09.2020 16:33, Julien Grall wrote:
> On 25/09/2020 14:58, Jan Beulich wrote:
>> On 25.09.2020 15:16, Julien Grall wrote:
>>> Fair enough. I would still like to consider a way where we could avoid
>>> to hack xsm_* because we have the interrupts disabled.
>>
>> Well, from a conceptual pov it's
On 25.09.2020 16:57, Jürgen Groß wrote:
> On 25.09.20 14:21, Jan Beulich wrote:
>> On 25.09.2020 12:34, Julien Grall wrote:
>>> On 24/09/2020 11:53, Jan Beulich wrote:
xmalloc() & Co may not be called with IRQs off, or else check_lock()
will have its assertion trigger about locks getting
ervisor instruction fetch in kernel mode
[8.480669][T0] #PF: error_code(0x0010) - not-present page
[8.486518][T0] PGD 0 P4D 0
[8.489757][T0] Oops: 0010 [#1] SMP KASAN PTI
[8.494476][T0] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G I
5.9.0-rc6-next-20200925 #2
[
On 25.09.20 14:21, Jan Beulich wrote:
On 25.09.2020 12:34, Julien Grall wrote:
On 24/09/2020 11:53, Jan Beulich wrote:
xmalloc() & Co may not be called with IRQs off, or else check_lock()
will have its assertion trigger about locks getting acquired
inconsistently. Re-arranging the locking in ev
Hi Jan,
On 25/09/2020 14:58, Jan Beulich wrote:
On 25.09.2020 15:16, Julien Grall wrote:
Hi Jan,
On 25/09/2020 13:21, Jan Beulich wrote:
On 25.09.2020 12:34, Julien Grall wrote:
On 24/09/2020 11:53, Jan Beulich wrote:
xmalloc() & Co may not be called with IRQs off, or else check_lock()
will
On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver. Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical differenc
When running as Xen dom0 the kernel isn't responsible for selecting the
error handling mode, this should be handled by the hypervisor.
So disable setting FF mode when running as Xen pv guest. Not doing so
might result in boot splats like:
[7.509696] HEST: Enabling Firmware First mode for corr
On 25.09.2020 15:45, boris.ostrov...@oracle.com wrote:
> On 9/25/20 6:11 AM, Juergen Gross wrote:
>> @@ -1296,6 +1296,14 @@ asmlinkage __visible void __init
>> xen_start_kernel(void)
>>
>> xen_smp_init();
>>
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Disable selecting "Firmware First mo
On 25.09.2020 15:16, Julien Grall wrote:
> Hi Jan,
>
> On 25/09/2020 13:21, Jan Beulich wrote:
>> On 25.09.2020 12:34, Julien Grall wrote:
>>> On 24/09/2020 11:53, Jan Beulich wrote:
xmalloc() & Co may not be called with IRQs off, or else check_lock()
will have its assertion trigger abou
On Wed, Sep 16, 2020 at 08:34:10PM +0200, David Hildenbrand wrote:
> Page isolation doesn't actually touch the pages, it simply isolates
> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
>
> We already place pages to the tail of the freelists when undoing
> isolation via __put
On Wed, 2020-08-26 at 13:17 +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> The arch_.*_msi_irq[s] fallbacks are compiled in whether an architecture
> requires them or not. Architectures which are fully utilizing hierarchical
> irq domains should never call into that code.
>
> It's not
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 mode" for correctable memory
> + * errors, as this is the du
On 25.09.20 15:19, Oscar Salvador wrote:
> On Wed, Sep 16, 2020 at 08:34:09PM +0200, David Hildenbrand wrote:
>> __putback_isolated_page() already documents that pages will be placed to
>> the tail of the freelist - this is, however, not the case for
>> "order >= MAX_ORDER - 2" (see buddy_merge_lik
On 24/09/2020 14:58, Christoph Hellwig wrote:
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap us
On 25.09.20 10:03, Jan Beulich wrote:
Hi Jan.
On 24.09.2020 18:45, Oleksandr wrote:
On 24.09.20 14:16, Jan Beulich wrote:
Hi Jan
On 22.09.2020 21:32, Oleksandr wrote:
On 16.09.20 11:50, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
--- a/xen/common/memory.c
+++ b/
On Wed, Sep 16, 2020 at 08:34:09PM +0200, David Hildenbrand wrote:
> __putback_isolated_page() already documents that pages will be placed to
> the tail of the freelist - this is, however, not the case for
> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
> the case for all ex
On 22.09.2020 20:24, Andrew Cooper wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -4013,6 +4013,81 @@ static int gnttab_get_shared_frame_mfn(struct domain
> *d,
> return 0;
> }
>
> +int gnttab_acquire_resource(
> +struct domain *d, unsigned int id, unsign
Hi Jan,
On 25/09/2020 13:21, Jan Beulich wrote:
On 25.09.2020 12:34, Julien Grall wrote:
On 24/09/2020 11:53, Jan Beulich wrote:
xmalloc() & Co may not be called with IRQs off, or else check_lock()
will have its assertion trigger about locks getting acquired
inconsistently. Re-arranging the lo
> -Original Message-
> From: Lengyel, Tamas
> Sent: 24 September 2020 20:36
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; Daniel De Graaf
> ; George Dunlap ; Ian Jackson
> ; Jan Beulich ; Julien Grall
> ; Marek
> Marczykowski-Górecki ; Roger P
On 24.09.2020 15:10, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and update xen-domctx to dump some information describing the record.
>
> NOTE: Processing of the content during restore is currently limited to
> PV domains, and matches processing of the PV-only SHARED_INFO record
>
flight 154750 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154750/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On 25.09.2020 12:34, Julien Grall wrote:
> On 24/09/2020 11:53, Jan Beulich wrote:
>> xmalloc() & Co may not be called with IRQs off, or else check_lock()
>> will have its assertion trigger about locks getting acquired
>> inconsistently. Re-arranging the locking in evtchn_send() doesn't seem
>> ver
Ping? AFAICT this series is fully acked. Can it be committed soon?
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 15 September 2020 15:10
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant
> Subject: [PATCH v2 0/2] fix 'xl block-detach'
>
> From: Paul Durrant
>
> This
Hi Jan,
On 24/09/2020 11:53, Jan Beulich wrote:
xmalloc() & Co may not be called with IRQs off, or else check_lock()
will have its assertion trigger about locks getting acquired
inconsistently. Re-arranging the locking in evtchn_send() doesn't seem
very reasonable, especially since the per-chann
On Wed, Sep 16, 2020 at 08:34:08PM +0200, David Hildenbrand wrote:
> Let's prepare for additional flags and avoid long parameter lists of bools.
> Follow-up patches will also make use of the flags in __free_pages_ok(),
> however, I wasn't able to come up with a better name for the type - should
> b
When running as Xen dom0 the kernel isn't responsible for selecting the
error handling mode, this should be handled by the hypervisor.
So disable setting FF mode when running as Xen pv guest. Not doing so
might result in boot splats like:
[7.509696] HEST: Enabling Firmware First mode for corr
On 25.09.20 09:51, Jan Beulich wrote:
Hi Jan
On 24.09.2020 20:02, Oleksandr wrote:
On 24.09.20 19:02, Oleksandr wrote:
Julien, I noticed that three fields mmio* are not used within current
series on Arm. Do we expect them to be used later on?
I would rather not add fields which are not used.
Hi
Am 23.09.20 um 16:33 schrieb Christian König:
> Feel free to add an Acked-by: Christian König
> to all patches which I haven't explicitly reviewed.
Done, thanks.
>
> I would say we should just push this to drm-misc-next now.
It's merged now.
Best regards
Thomas
>
> Thanks for the nice c
On 9/25/20 10:05 AM, David Hildenbrand wrote:
static inline void del_page_from_free_list(struct page *page, struct zone
*zone,
unsigned int order)
{
@@ -2323,7 +2332,7 @@ static inline struct page
*__rmqueue_cma_fallback(struct
> -Original Message-
> From: Julien Grall
> Sent: 24 September 2020 19:01
> To: Oleksandr Tyshchenko ; xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Andrew Cooper
> ;
> George Dunlap ; Ian Jackson
> ; Jan Beulich
> ; Stefano Stabellini ; Wei Liu
> ; Roger Pau
> Monné ; Pau
On 24.09.20 12:37, Vlastimil Babka wrote:
> On 9/16/20 8:34 PM, David Hildenbrand wrote:
>> __putback_isolated_page() already documents that pages will be placed to
>> the tail of the freelist - this is, however, not the case for
>> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should
On 25.09.20 04:45, Wei Yang wrote:
> On Thu, Sep 24, 2020 at 01:13:29PM +0200, Vlastimil Babka wrote:
>> On 9/16/20 8:34 PM, David Hildenbrand wrote:
>>> Page isolation doesn't actually touch the pages, it simply isolates
>>> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
>>>
branch xen-4.14-testing
xenbranch xen-4.14-testing
job test-xtf-amd64-amd64-1
testid xtf/test-hvm64-xsa-221
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenb
flight 154667 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154667/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 154358
test-xtf-amd64
On 24.09.2020 18:45, Oleksandr wrote:
>
> On 24.09.20 14:16, Jan Beulich wrote:
>
> Hi Jan
>
>> On 22.09.2020 21:32, Oleksandr wrote:
>>> On 16.09.20 11:50, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
>>
57 matches
Mail list logo
