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
---
drivers/xen/pvcalls-front.c | 2 +-
1 file changed, 1 insertion(+), 1
On Wed, Sep 16, 2020 at 02:25:14PM -0400, Eduardo Habkost wrote:
> This converts many QOM types to use OBJECT_DECLARE* instead of
> manually using DECLARE*_CHECKER*.
>
> Before doing that, I'm simplifying the OBJECT_DECLARE* API to
> make it easier to use and more difficult to misuse. The
>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Qinglang Miao
---
v2: based on linux-next(20200917), and can be applied to
mainline cleanly now.
arch/x86/xen/p2m.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/x86/xen/p2m.c
flight 154471 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154471/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
flight 154480 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154480/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 154468 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154468/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7faece69854cbcc593643182581b5d7f99b7dab6
baseline version:
ovmf
flight 154466 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154466/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
On Fri, 2020-09-18 at 16:03 -0400, Jeff Kubascik wrote:
> On 9/17/2020 1:30 PM, Dario Faggioli wrote:
> > On Thu, 2020-09-17 at 15:59 +, Stewart Hildebrand wrote:
> > >
> > And don't think only to the need of writing the code (as you kind
> > of
> > have it already), but also to testing. As
On 9/17/2020 1:30 PM, Dario Faggioli wrote:
>On Thu, 2020-09-17 at 15:59 +, Stewart Hildebrand wrote:
>> On Thursday, September 17, 2020 11:20 AM, Dario Faggioli wrote:
>>> On Thu, 2020-09-17 at 15:10 +, Stewart Hildebrand wrote:
> It might be worth to consider using just the core
flight 154465 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154465/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 154016
On 9/17/2020 1:57 PM, Stewart Hildebrand wrote:
> On Thursday, September 17, 2020 12:19 PM, Andrew Cooper wrote:
>> On 17/09/2020 15:57, Stewart Hildebrand wrote:
>>> On Thursday, September 17, 2020 10:43 AM, Andrew Cooper wrote:
On 16/09/2020 19:18, Jeff Kubascik wrote:
> +/*
> + * A
flight 154475 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154475/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi all,
I was going to commit this patch but I realized that I still don't have
a review from the maintainers of...
On 30/07/2020 19:18, Julien Grall wrote:
xen/arch/x86/hvm/viridian/viridian.c | 2 +-
... this file (Paul and Wei) and...
xen/arch/x86/hvm/vmx/vmx.c | 2 +-
..
Hi Daniel,
On 17/09/2020 10:47, Daniel Wagner2 wrote:
Btw 8_8000_ is the start address of this systems DDR Main
memory, according to the Reference Manual of the i.MX8QXP.
I couldn't find this value in the DT. It is possible that U-boot is
modifying the memory node before jumping to Xen (or
Hi Andre,
On 17/09/2020 10:46, André Przywara wrote:
On 17/09/2020 01:31, Stefano Stabellini wrote:
Hi,
On Wed, 16 Sep 2020, Julien Grall wrote:
On 14/09/2020 15:26, Daniel Wagner2 wrote:
Hi Julien,
Hi Daniel,
I am moving the thread to xen-devel and adding a couple of more folks.
On 9/17/2020 10:16 AM, Dario Faggioli wrote:
>On Thu, 2020-09-17 at 10:12 +0200, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> @@ -517,27 +516,35 @@ static const struct scheduler
>>> sched_arinc653_def = {
>>> .sched_id = XEN_SCHEDULER_ARINC653,
>>>
On 9/17/2020 10:17 AM, Andrew Cooper wrote:
> On 17/09/2020 09:12, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> @@ -517,27 +516,35 @@ static const struct scheduler sched_arinc653_def = {
>>> .sched_id = XEN_SCHEDULER_ARINC653,
>>> .sched_data = NULL,
>>>
On 9/17/2020 10:17 AM, Andrew Cooper wrote:
> On 17/09/2020 09:12, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> @@ -517,27 +516,35 @@ static const struct scheduler sched_arinc653_def = {
>>> .sched_id = XEN_SCHEDULER_ARINC653,
>>> .sched_data = NULL,
>>>
On 9/17/2020 10:40 AM, Dario Faggioli wrote:
>On Thu, 2020-09-17 at 10:09 +0200, Jan Beulich wrote:
>> On 16.09.2020 20:18, Jeff Kubascik wrote:
>>> --- a/xen/common/sched/arinc653.c
>>> +++ b/xen/common/sched/arinc653.c
>>> @@ -119,10 +119,9 @@ static int dom_handle_cmp(const
>>>
From: Julien Grall
At the moment, Xen will stop processing the Device Tree if a memory
bank is empty (size == 0).
Unfortunately, some of the Device Tree (such as on Colibri imx8qxp)
may contain such a bank. This means Xen will not be able to boot
properly.
Relax the check to just ignore the
Open code alloc_vm_area in the last remaining caller.
Signed-off-by: Christoph Hellwig
---
arch/x86/xen/grant-table.c | 27 +++--
include/linux/vmalloc.h| 5 +---
mm/nommu.c | 7 --
mm/vmalloc.c | 48 --
Replacing alloc_vm_area with get_vm_area_caller + apply_page_range
allows to fill put the phys_addr values directly instead of doing
another loop over all addresses.
Signed-off-by: Christoph Hellwig
---
drivers/xen/xenbus/xenbus_client.c | 30 --
1 file changed, 16
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
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 using a flag
if actually required).
Signed-off-by:
Add a proper helper to remap PFNs into kernel virtual space so that
drivers don't have to abuse alloc_vm_area and open coded PTE
manipulation for it.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 1 +
mm/Kconfig | 3 +++
mm/vmalloc.c| 45
There is no obvious reason why zsmalloc needs to pre-fault the PTEs
given that it later uses map_kernel_range to just like vmap().
Signed-off-by: Christoph Hellwig
---
mm/zsmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index
Hi all. Michael Tokarev has been looking into the problem that qemu
is using Xen libraries with usntable ABIs. We did an experiment to
see which abi-unstable symbols qemu links to, by suppressing libxc
from the link line. The results are below.[1]
Things are not looking too bad. After some
Hi Andrew,
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 originally addeds for Xen (which isn't
modular to start
>On Thu, 2020-09-17 at 13:09 +0100, Andrew Cooper wrote:
>> On 16/09/2020 19:18, Jeff Kubascik wrote:
>>> diff --git a/xen/common/sched/arinc653.c
>>> b/xen/common/sched/arinc653.c
>>> index 7bb75ffe2b..d8a23730c3 100644
>>> --- a/xen/common/sched/arinc653.c
>>> +++ b/xen/common/sched/arinc653.c
On 9/17/2020 9:24 AM, Andrew Cooper wrote:
> On 16/09/2020 19:18, Jeff Kubascik wrote:
>> -/**
>> - * Retrieve the idle UNIT for a given physical CPU
>> +/*
>> + * Retrieve the idle UNIT for a given pCPU
>> */
>
> /** is also acceptable. We've inherited quite a few doxygen-like
> comments, and
On 17.09.2020 17:40, Trammell Hudson wrote:
> @@ -1155,8 +1184,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> *SystemTable)
> PrintErrMesg(L"No Loaded Image Protocol", status);
>
> efi_arch_load_addr_check(loaded_image);
> +secure = efi_secure_boot();
>
> -if
On 17.09.2020 17:40, Trammell Hudson wrote:
> @@ -624,6 +626,29 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle,
> CHAR16 *name,
> return true;
> }
>
> +static bool __init read_section(const EFI_LOADED_IMAGE *image,
> +char *const name, struct
On 17.09.2020 17:40, Trammell Hudson wrote:
> Add a separate function to display the address ranges used by
> the files and call `efi_arch_handle_module()` on the modules.
>
> Signed-off-by: Trammell Hudson
You've lost the ack I gave, and ...
> --- a/xen/common/efi/boot.c
> +++
On 17.09.2020 17:40, Trammell Hudson wrote:
> The config file, kernel, initrd, etc should only be freed if they
> are allocated with the UEFI allocator.
>
> Signed-off-by: Trammell Hudson
Hmm, this hasn't changed from v4, despite the review requests.
Any particular reason?
Jan
On 17.09.2020 17:40, Trammell Hudson wrote:
> Other than the config file parser that edits the image inplace,
> no other users of the file sections requires write access to the
> data.
>
> Signed-off-by: Trammell Hudson
Reviewed-by: Jan Beulich
albeit ...
> @@ -592,7 +593,7 @@ static bool
flight 154461 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154461/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
flight 154127 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154127/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
flight 154124 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/154124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 11 guest-start fail REGR. vs. 154016
flight 154448 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154448/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332
On 18.09.20 04:30, Wei Yang wrote:
> On Wed, Sep 16, 2020 at 09:31:21PM +0200, David Hildenbrand wrote:
>>
>>
>>> Am 16.09.2020 um 20:50 schrieb osalva...@suse.de:
>>>
>>> On 2020-09-16 20:34, David Hildenbrand wrote:
When adding separate memory blocks via add_memory*() and onlining them
flight 154452 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154452/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 698d3d7726232694018d437279dd4166e462deb7
baseline version:
ovmf
On 18.09.20 04:29, Wei Yang wrote:
> 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
On 18.09.20 04:16, Wei Yang 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 18.09.20 04:07, Wei Yang 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
flight 154454 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154454/
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
On 18.09.20 03:53, Wei Yang wrote:
> 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
46 matches
Mail list logo
