flight 155231 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155231/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 6 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
flight 155226 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155226/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
test-amd64-i386-xl-qemut-debianhvm-i3
branch xen-4.12-testing
xenbranch xen-4.12-testing
job test-amd64-amd64-libvirt-xsm
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: l
branch xen-4.14-testing
xenbranch xen-4.14-testing
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
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/ovm
flight 155222 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155222/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-arm64-arm64-xl-seattle 13 migrate
On 24/09/2020 14:10, Paul Durrant wrote:
> From: Paul Durrant
>
> The STATIC_DATA_END, X86_CPUID_POLICY and X86_MSR_POLICY record types have
> sections explaining what they are but their values are not defined. Indeed
> their values are defined as "Reserved for future mandatory records."
>
> Also,
On 24/09/2020 14:10, Paul Durrant wrote:
> This tool is analogous to 'xen-hvmctx' which presents HVM context.
> Subsequent patches will add 'dump' functions when new records are
> introduced.
>
> Signed-off-by: Paul Durrant
> Acked-by: Ian Jackson
> ---
> Cc: Andrew Cooper
> Cc: Wei Liu
>
> NOT
flight 155223 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155223/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2d8ca4f90eaeb61bd7e9903b56bf412f0d187137
baseline version:
ovmf d8ab884fe9b4dd148980b
On 24/09/2020 14:10, Paul Durrant wrote:
> +/*
> + * The 'dry_run' flag indicates that the caller of domain_save() (see below)
> + * is not trying to actually acquire the data, only the size of the data.
> + * The save handler can therefore limit work to only that which is necessary
> + * to call d
On 24/09/2020 14:10, Paul Durrant wrote:
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 791f0a2592..743105181f 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1130,6 +1130,43 @@ struct xen_domctl_vuart_op {
>
flight 155349 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155349/
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 1
c/s 4304ff420e5 "x86/S3: Drop {save,restore}_rest_processor_state()
completely" moved CR4 restoration up into C, to account for the fact that MCE
was explicitly handled later.
However, time_resume() ends up making an EFI Runtime Service call, and EFI
explodes without OSFXSR, presumably when trying
On 24/09/2020 14:10, Paul Durrant wrote:
> diff --git a/xen/common/save.c b/xen/common/save.c
> new file mode 100644
> index 00..841c4d0e4e
> --- /dev/null
> +++ b/xen/common/save.c
> @@ -0,0 +1,315 @@
> +/*
> + * save.c: Save and restore PV guest state common to all domain types.
This des
The preferred methord to reboot RPi4 is PSCI. If it is not available,
touching the watchdog is required to be able to reboot the board.
The implementation is based on
drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7.
Signed-off-by: Stefano Stabellini
CC: ro...@zededa.com
---
Ch
On Fri, 2 Oct 2020, Christoph Hellwig wrote:
> Hi Stefano,
>
> I've looked over xen-swiotlb in linux-next, that is with your recent
> changes to take dma offsets into account. One thing that puzzles me
> is that xen_swiotlb_map_page passes virt_to_phys(xen_io_tlb_start) as
> the tbl_dma_addr argu
On Fri, Oct 02, 2020 at 04:42:50PM +0100, Andrew Cooper wrote:
> On 02/10/2020 16:39, Jan Beulich wrote:
> > On 02.10.2020 17:08, Marek Marczykowski-Górecki wrote:
> >> I've done another bisect on the commit broken up in separate changes
> >> (https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen
On Tue, Sep 29, 2020 at 05:14:37PM +0200, Thomas Zimmermann wrote:
> Instances of struct dma_buf_map should be useful throughout DRM's
> memory management code. Furthermore, several drivers can now use
> generic fbdev emulation.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
> --
On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote:
>
> On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with direct access to the framebuf
On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for t
branch xen-4.11-testing
xenbranch xen-4.11-testing
job test-amd64-i386-xl-qemut-debianhvm-i386-xsm
testid debian-hvm-install
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
On 10/2/2020 8:25 PM, Stefano Stabellini wrote:
> On Fri, 2 Oct 2020, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor
>>
>> Don't hardcode the lookup start level of the page table walk to 1
>> and instead match the one used in P2M. This should fix scenarios
>> involving SMMU where the st
OSSTest reports that libvirt is reliably regressed.
The only possible option is a side effect of using libxl_defbool_val(), which
can only be the assert() within. Unfortunately, libvirt actually crashes in
__vfscanf_internal() while presuambly trying to render some form of error.
Opencode the ch
On Fri, 2 Oct 2020, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> Don't hardcode the lookup start level of the page table walk to 1
> and instead match the one used in P2M. This should fix scenarios
> involving SMMU where the start level is different than 1.
> In order for the SMMU d
flight 155211 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155211/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 154611
test-amd64-i386-li
* Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> Restricting xen-set-global-dirty-log and xen-load-devices-state
> commands migration.json pulls slightly less QAPI-generated code
> into user-mode and tools.
>
> Signed-off-by: Philippe Mathieu-Daudé
Looks OK; for migration
Acked-by: Dr.
flight 155327 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155327/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
On 10/2/2020 7:36 PM, Julien Grall wrote:
> Hi,
>
> On 02/10/2020 11:33, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor
>>
>> Don't hardcode the lookup start level of the page table walk to 1
>> and instead match the one used in P2M. This should fix scenarios
>> involving SMMU where t
Hi,
On 02/10/2020 11:33, laurentiu.tu...@nxp.com wrote:
From: Laurentiu Tudor
Don't hardcode the lookup start level of the page table walk to 1
and instead match the one used in P2M. This should fix scenarios
involving SMMU where the start level is different than 1.
In order for the SMMU drive
On 02.10.20 18:06, Edwin Török wrote:
See
https://lore.kernel.org/xen-devel/20201002154141.11677-6-jgr...@suse.com/T/#u
Edwin Török (1):
tools/ocaml/xenstored: drop the creation of the RO socket
tools/ocaml/xenstored/connections.ml | 2 +-
tools/ocaml/xenstored/define.ml | 1 -
t
See
https://lore.kernel.org/xen-devel/20201002154141.11677-6-jgr...@suse.com/T/#u
Edwin Török (1):
tools/ocaml/xenstored: drop the creation of the RO socket
tools/ocaml/xenstored/connections.ml | 2 +-
tools/ocaml/xenstored/define.ml | 1 -
tools/ocaml/xenstored/xenstored.ml | 15 +++
The readonly flag was propagated but ignored, so this was essentially
equivalent to a RW socket.
C xenstored is dropping the RO socket too, so drop it from oxenstored too.
Signed-off-by: Edwin Török
---
tools/ocaml/xenstored/connections.ml | 2 +-
tools/ocaml/xenstored/define.ml | 1 -
t
On 02/10/2020 16:39, Jan Beulich wrote:
> On 02.10.2020 17:08, Marek Marczykowski-Górecki wrote:
>> I've done another bisect on the commit broken up in separate changes
>> (https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/dbg-s3)
>> and the bad part seems to be th
The read-only socket of Xenstore is usable for the daemon case only
and even there it is not really worth to be kept, as not all
Xesntore operations changing the state of Xenstore are blocked,
oxenstored ignoring the read-only semantics completely, and the
privileges for using the ro-socket being t
Switch all usages of xs_daemon_open*() and xs_domain_open() to use
xs_open() instead. While at it switch xs_daemon_close() users to
xs_close().
Signed-off-by: Juergen Gross
---
tools/console/client/main.c | 2 +-
tools/console/daemon/utils.c| 4 ++--
tools/libs/light/li
When opening the connection to Xenstore via xs_open() it makes no
sense to limit the connection to the socket based one. So just ignore
the XS_OPEN_SOCKETONLY flag.
Signed-off-by: Juergen Gross
---
tools/libs/store/include/xenstore.h | 2 --
tools/libs/store/xs.c | 2 +-
2 files ch
With xs_daemon_open_readonly() now no longer using the read-only socket
the creation of that socket can be dropped.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 55 +++
tools/xenstore/xenstored_core.h | 3 --
tools/xenstore/xenstored_domain.
Today it is possible to open the connection in read-only mode via
xs_daemon_open_readonly(). This is working only with Xenstore running
as a daemon in the same domain as the user. Additionally it doesn't
add any security as accessing the socket used for that functionality
requires the same privileg
The Xenstore access commands (xenstore-*) have the possibility to limit
connection to Xenstore to a local socket (option "-s"). This is an
option making no sense at all, as either there is only a socket, so
the option would be a nop, or there is no socket at all (in case
Xenstore is running in a st
On 02.10.2020 17:08, Marek Marczykowski-Górecki wrote:
> I've done another bisect on the commit broken up in separate changes
> (https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/dbg-s3)
> and the bad part seems to be this:
>
> From dbdb32f8c265295d6af7cd4cd0aa12b
On 30.09.2020 12:41, Roger Pau Monne wrote:
> Remove the unconditional call to hvm_dpci_msi_eoi in vlapic_handle_EOI
> and instead use the newly introduced EOI callback mechanism in order
> to register a callback for MSI vectors injected from passed through
> devices.
What I'm kind of missing here
On 02.10.20 15:24, Michal Hocko wrote:
> On Mon 28-09-20 20:21:08, 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 u
On 02.10.20 15:41, Michal Hocko wrote:
> On Mon 28-09-20 20:21:09, David Hildenbrand wrote:
>> __free_pages_core() is used when exposing fresh memory to the buddy
>> during system boot and when onlining memory in generic_online_page().
>>
>> generic_online_page() is used in two cases:
>>
>> 1. Dire
On Thu, Oct 01, 2020 at 01:43:52PM +0100, Andrew Cooper wrote:
> On 01/10/2020 13:31, Marek Marczykowski-Górecki wrote:
> > On Thu, Oct 01, 2020 at 01:59:32PM +0200, Jan Beulich wrote:
> >> On 01.10.2020 03:12, Marek Marczykowski-Górecki wrote:
> >>> After patching the previous issue ("x86/S3: Fix
On 02.10.20 16:48, David Hildenbrand wrote:
> On 02.10.20 15:41, Matthew Wilcox wrote:
>> On Mon, Sep 28, 2020 at 08:21:06PM +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 __fre
On 02.10.20 15:41, Matthew Wilcox wrote:
> On Mon, Sep 28, 2020 at 08:21:06PM +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 u
Instead of using symbolic links to include files from xenstored use
the vpath directive and an include path.
Signed-off-by: Juergen Gross
---
tools/libs/store/Makefile | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/tools/libs/store/Makefile b/tools/libs/store/Makefil
Instead of using symbolic links for accessing the xenctrl private
headers use an include path instead.
Signed-off-by: Juergen Gross
---
tools/libs/guest/Makefile | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/tools/libs/guest/Makefile b/tools/libs/guest/Makefile
ind
Instead of each library having an own include directory move the
official headers to tools/include instead. This will drop the need to
link those headers to tools/include and there is no need any longer
to have library-specific include paths when building Xen.
While at it remove setting of the unu
The rework of the Xen library build introduced creating some additional
symbolic links during the build process.
This series is undoing that by moving all official Xen library headers
to tools/include and by using include paths and the vpath directive
when access to some private headers of another
> On 2 Oct 2020, at 12:03, Bertrand Marquis wrote:
>
>
>
>> On 2 Oct 2020, at 11:44, Jürgen Groß wrote:
>>
>> On 02.10.20 12:12, Bertrand Marquis wrote:
>>> Hi,
On 2 Oct 2020, at 08:25, Jürgen Groß wrote:
On 02.10.20 08:59, Jan Beulich wrote:
> On 02.10.2020 08:51, Jürg
flight 155321 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155321/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 155128
Tests which
On Mon 28-09-20 20:21:10, David Hildenbrand wrote:
> As we no longer shuffle via generic_online_page() and when undoing
> isolation, we can simplify the comment.
>
> We now effectively shuffle only once (properly) when onlining new
> memory.
>
> Cc: Andrew Morton
> Cc: Alexander Duyck
> Cc: Mel
On Mon, Sep 28, 2020 at 08:21:06PM +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
On Mon 28-09-20 20:21:09, David Hildenbrand wrote:
> __free_pages_core() is used when exposing fresh memory to the buddy
> during system boot and when onlining memory in generic_online_page().
>
> generic_online_page() is used in two cases:
>
> 1. Direct memory onlining in online_pages().
> 2. De
Restricting system_wakeup/system_reset/system_powerdown to
machine.json pulls slightly less QAPI-generated code into
user-mode and tools.
Signed-off-by: Philippe Mathieu-Daudé
---
qapi/machine.json | 57 +++
qapi/misc.json| 57 -
Restricting memsave/pmemsave to machine.json pulls slightly
less QAPI-generated code into user-mode and tools.
Signed-off-by: Philippe Mathieu-Daudé
---
qapi/machine.json | 61 +++
qapi/misc.json| 61 ---
Restricting xen-set-global-dirty-log and xen-load-devices-state
commands migration.json pulls slightly less QAPI-generated code
into user-mode and tools.
Signed-off-by: Philippe Mathieu-Daudé
---
qapi/migration.json| 41 +
qapi/misc.json | 41 -
> On 2 Oct 2020, at 14:17, Jan Beulich wrote:
>
> On 02.10.2020 14:44, Bertrand Marquis wrote:
>>
>>
>>> On 2 Oct 2020, at 13:38, Jan Beulich wrote:
>>>
>>> On 02.10.2020 14:34, Bertrand Marquis wrote:
> On 2 Oct 2020, at 13:12, Jan Beulich wrote:
>
> On 02.10.2020 12:42, Bert
Restricting query-kvm to machine.json pulls slightly
less QAPI-generated code into user-mode and tools.
Signed-off-by: Philippe Mathieu-Daudé
---
qapi/machine.json | 30 ++
qapi/misc.json| 30 --
2 files changed, 30 insertions(+), 30 de
Restricting 'inject-nmi' to machine.json pulls slightly
less QAPI-generated code into user-mode and tools.
Signed-off-by: Philippe Mathieu-Daudé
---
qapi/machine.json | 20
qapi/misc.json| 20
softmmu/cpus.c| 1 +
3 files changed, 21 insertions(
Reduce the machine code pulled into qemu-storage-daemon.
Philippe Mathieu-Daudé (5):
qapi: Restrict 'inject-nmi' command to machine code
qapi: Restrict 'system wakeup/reset/powerdown' commands to
machine.json
qapi: Restrict '(p)memsave' command to machine code
qapi: Restrict 'query-kvm
On Mon 28-09-20 20:21:08, 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 __putback_isolated_pa
On Mon 28-09-20 20:21:07, 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 existing users.
>
On Mon 28-09-20 20:21:06, 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
> be good enough fo
On 02.10.2020 14:44, Bertrand Marquis wrote:
>
>
>> On 2 Oct 2020, at 13:38, Jan Beulich wrote:
>>
>> On 02.10.2020 14:34, Bertrand Marquis wrote:
On 2 Oct 2020, at 13:12, Jan Beulich wrote:
On 02.10.2020 12:42, Bertrand Marquis wrote:
> Modify Makefiles using $(XEN_ROOT)/xen
On Tue, Sep 29, 2020 at 05:14:35PM +0200, Thomas Zimmermann wrote:
> Kernel DRM clients now store their framebuffer address in an instance
> of struct dma_buf_map. Depending on the buffer's location, the address
> refers to system or I/O memory.
>
> Callers of drm_client_buffer_vmap() receive a co
On Tue, Sep 29, 2020 at 05:14:34PM +0200, Thomas Zimmermann wrote:
> GEM's vmap and vunmap interfaces now wrap memory pointers in struct
> dma_buf_map.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_client.c | 18 +++---
> drivers/gpu/drm/drm_gem.c | 28 +
On Tue, Sep 29, 2020 at 05:14:33PM +0200, Thomas Zimmermann wrote:
> This patch replaces the vmap/vunmap's use of raw pointers in GEM object
> functions with instances of struct dma_buf_map. GEM backends are
> converted as well.
>
> For most GEM backends, this simply change the returned type. GEM
> On 2 Oct 2020, at 13:38, Jan Beulich wrote:
>
> On 02.10.2020 14:34, Bertrand Marquis wrote:
>>> On 2 Oct 2020, at 13:12, Jan Beulich wrote:
>>>
>>> On 02.10.2020 12:42, Bertrand Marquis wrote:
Modify Makefiles using $(XEN_ROOT)/xen to use $(BASEDIR) instead.
This is removin
On 02.10.2020 14:34, Bertrand Marquis wrote:
>> On 2 Oct 2020, at 13:12, Jan Beulich wrote:
>>
>> On 02.10.2020 12:42, Bertrand Marquis wrote:
>>> Modify Makefiles using $(XEN_ROOT)/xen to use $(BASEDIR) instead.
>>>
>>> This is removing the dependency to xen subdirectory preventing using a
>>> wr
> On 2 Oct 2020, at 13:12, Jan Beulich wrote:
>
> On 02.10.2020 12:42, Bertrand Marquis wrote:
>> Modify Makefiles using $(XEN_ROOT)/xen to use $(BASEDIR) instead.
>>
>> This is removing the dependency to xen subdirectory preventing using a
>> wrong configuration file when xen subdirectory is
Hi Stefano,
I've looked over xen-swiotlb in linux-next, that is with your recent
changes to take dma offsets into account. One thing that puzzles me
is that xen_swiotlb_map_page passes virt_to_phys(xen_io_tlb_start) as
the tbl_dma_addr argument to swiotlb_tbl_map_single, despite the fact
that the
On 02.10.2020 13:19, Andrew Cooper wrote:
> On 02/10/2020 11:31, Jan Beulich wrote:
>> Hence there's no need to guard allocation / mapping by checks whether
>> the same action has been done before. I assume this was a transient
>> change which should have been undone before 509529e99148 ("x86 hvm:
On 02.10.2020 13:13, Andrew Cooper wrote:
> On 02/10/2020 11:30, Jan Beulich wrote:
>> {hvm,pv}_vcpu_initialise() have always been meant to be the final
>> possible source of errors in arch_vcpu_create(), hence not requiring
>> any unrolling of what they've done on the error path. (Of course this
>
All users are gone now.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 5 +
mm/nommu.c | 7 --
mm/vmalloc.c| 48 -
3 files changed, 1 insertion(+), 59 deletions(-)
diff --git a/include/linux/vmalloc.h b/i
Replace the last call to alloc_vm_area with an open coded version using
an iterator in struct gnttab_vm_area instead of the triple indirection
magic in alloc_vm_area.
Signed-off-by: Christoph Hellwig
Reviewed-by: Boris Ostrovsky
---
arch/x86/xen/grant-table.c | 27 ---
1
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
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/g
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). Switch to use v
Just manually pre-fault the PTEs using apply_to_page_range.
Co-developed-by: Minchan Kim
Signed-off-by: Christoph Hellwig
---
mm/zsmalloc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index c36fdff9a37131..918c7b019b3d78 100644
--
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 ++
From: "Matthew Wilcox (Oracle)"
* Document that you can call vfree() on an address returned from vmap()
* Remove the note about the minimum size -- the minimum size of a vmalloc
allocation is one page
* Add a Context: section
* Fix capitalisation
* Reword the prohibition on calling from N
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
Reviewed-by: Boris Ostrovsky
---
drivers/xen/xenbus/xenbus_client.c | 30 ---
Besides calling the callback on each page, apply_to_page_range also has
the effect of pre-faulting all PTEs for the range. To support callers
that only need the pre-faulting, make the callback optional.
Based on a patch from Minchan Kim .
Signed-off-by: Christoph Hellwig
---
mm/memory.c | 16 +
Add a flag so that vmap takes ownership of the passed in page array.
When vfree is called on such an allocation it will put one reference
on each page, and free the page array itself.
Signed-off-by: Christoph Hellwig
---
include/linux/vmalloc.h | 1 +
mm/vmalloc.c| 9 +++--
2 fil
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 w
On Fri, Oct 2, 2020 at 1:30 PM Christian König
wrote:
>
> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> >> wrote:
> >>> Am 30.09.20 um 11:47 schrieb Daniel Vetter:
> On Wed
On 02.10.2020 12:42, Bertrand Marquis wrote:
> Modify Makefiles using $(XEN_ROOT)/xen to use $(BASEDIR) instead.
>
> This is removing the dependency to xen subdirectory preventing using a
> wrong configuration file when xen subdirectory is duplicated for
> compilation tests.
>
> Signed-off-by: Be
On 02.10.2020 13:30, Andrew Cooper wrote:
> The error message is wrong (given AMD's older interpretation of what a NUL
> segment should contain, attribute wise), and actively unhelpful because you
> only get it in response to a hypercall where the one piece of information you
> cannot provide is th
On 02/10/2020 03:22, osstest service owner wrote:
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: xen git://xenbits.xen.org/xen.git
> Bug introduced: bfcc97c08c2258316d1cd92c23a441d97ad6ff4e
> Bug not present: 50a5215f30e964a6f16165ab57925ca39f31a849
> Last fail repro
On Thu, Oct 01, 2020 at 06:03:09PM +0200, Jan Beulich wrote:
> On 10.09.2020 14:09, Jan Beulich wrote:
> > While looking at what it would take to move around libelf/
> > in the hypervisor subtree, I've run into this rule, which I
> > think can do with a few improvements and some simplification.
> >
The error message is wrong (given AMD's older interpretation of what a NUL
segment should contain, attribute wise), and actively unhelpful because you
only get it in response to a hypercall where the one piece of information you
cannot provide is the segment selector.
Fix the message to talk about
Am 02.10.20 um 11:58 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
On Wed, Sep 30, 2020 at 2:34 PM Christian König
wrote:
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19
On 02/10/2020 11:31, Jan Beulich wrote:
> Hence there's no need to guard allocation / mapping by checks whether
> the same action has been done before. I assume this was a transient
> change which should have been undone before 509529e99148 ("x86 hvm: Xen
> interface and implementation for virtual
This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
configuration file, the Linux kernel and initrd, as well as the XSM,
and architectural specific files into a single "unified" EFI executable.
This allows an administrator to update the components independently
without requirin
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
Acked-by: Jan Beulich
---
xen/common/efi/boot.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --
If a unified Xen image is used, then the bundled configuration,
Xen command line, dom0 kernel, and ramdisk are prefered over
any files listed in the config file or provided on the command line.
Unlike the shim based verification, the PE signature on a unified image
covers all of the Xen+config+ker
The config file, kernel, initrd, etc should only be freed if they
are allocated with the UEFI allocator. On x86 the ucode, and on
ARM the dtb, are also marked as need_to_free when allocated or
expanded.
This also fixes a memory leak in ARM fdt_increase_size() if there
is an error in building the
This patch series adds support for bundling the xen.efi hypervisor,
the xen.cfg configuration file, the Linux kernel and initrd, as well
as the XSM, and architectural specific files into a single "unified"
EFI executable. This allows an administrator to update the components
independently without
On 02/10/2020 11:30, Jan Beulich wrote:
> {hvm,pv}_vcpu_initialise() have always been meant to be the final
> possible source of errors in arch_vcpu_create(), hence not requiring
> any unrolling of what they've done on the error path. (Of course this
> may change once the various involved paths all
1 - 100 of 142 matches
Mail list logo
