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
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
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
> [
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
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
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
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
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
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
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
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
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
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
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
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
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
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
struction 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
[8.5039
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
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()
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
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
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
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
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
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
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
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
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
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
+++
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
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,
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
> -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
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
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
>>
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
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
>
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
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
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
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
> -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é ;
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
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
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
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
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. We could add them when
> needed.
>
>
On 24.09.2020 23:48, Elliott Mitchell wrote:
> On Thu, Sep 24, 2020 at 05:44:09PM +0200, Jan Beulich wrote:
>> On 02.09.2020 03:08, Elliott Mitchell wrote:
>>> @@ -33,12 +38,12 @@ cscope.po.out
>>> .vscode
>>>
>>> dist
>>> -stubdom/*.tar.gz
>>>
>>> autom4te.cache/
>>> config.log
>>>
This series fixes builds of libxenguest users outside the Xen build
system and it cleans up the xenguest.h header merging xenctrl_dom.h
into it.
Juergen Gross (3):
tools/libs: merge xenctrl_dom.h into xenguest.h
tools/libxenguest: make xc_dom_loader interface private to libxenguest
The pluggable kernel loader interface is used only internally of
libxenguest, so make it private. This removes a dependency on the Xen
internal header xen/libelf/libelf.h from xenguest.h.
Signed-off-by: Juergen Gross
---
tools/libs/guest/include/xenguest.h | 15 ---
Today xenctrl_dom.h is part of libxenctrl as it is included by
xc_private.c. This seems not to be needed, so merge xenctrl_dom.h into
xenguest.h where its contents really should be.
Replace all #includes of xenctrl_dom.h by xenguest.h ones or drop them
if xenguest.h is already included.
Don't include struct elf_dom_parms in struct xc_dom_image, but rather
use a pointer to reference it. Together with adding accessor functions
for the externally needed elements this enables to drop including the
Xen private header xen/libelf/libelf.h from xenguest.h.
Fixes: 7e0165c19387
flight 154675 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154675/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
62 matches
Mail list logo
