On 05.10.20 18:02, Bertrand Marquis wrote:
Use memcpy in getBridge to prevent gcc warnings about truncated
strings. We know that we might truncate it, so the gcc warning
here is wrong.
Revert previous change changing buffer sizes as bigger buffers
are not needed.
Signed-off-by: Bertrand Marquis
On Tue, 6 Oct 2020 11:40:58 +0900
Masami Hiramatsu wrote:
> On Mon, 5 Oct 2020 18:13:22 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > On Mon, 5 Oct 2020, Julien Grall wrote:
> > > Hi Masami,
> > >
> > > On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > > > Use per_cpu_ptr_to_phys() instead of
On Mon, 5 Oct 2020 18:13:22 -0700 (PDT)
Stefano Stabellini wrote:
> On Mon, 5 Oct 2020, Julien Grall wrote:
> > Hi Masami,
> >
> > On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > > Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
> > > address conversion.
> > >
> > > In
On Mon, 5 Oct 2020, Julien Grall wrote:
> Hi Masami,
>
> On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
> > address conversion.
> >
> > In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
> > to gfn by virt_to_gfn()
On Mon, 5 Oct 2020 19:18:47 +0100
Julien Grall wrote:
> Hi Masami,
>
> On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
> > address conversion.
> >
> > In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
> > to gfn
On Fri, Oct 02, 2020 at 10:36:50PM +0100, Andrew Cooper wrote:
> 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
On Mon, Oct 05, 2020 at 01:23:25PM +0100, Andrew Cooper wrote:
> For simplicity between various configuration, Xen always uses shadow stack
> mappings (Read-only + Dirty) for the guard page, irrespective of whether
> CET-SS is enabled.
>
> memguard_guard_stack() writes shadow stack tokens with
Hi Masami,
On 05/10/2020 14:39, Masami Hiramatsu wrote:
Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
address conversion.
In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
to gfn by virt_to_gfn() macro. However, since the virt_to_gfn(v)
assumes the given
On Mon, Oct 05, 2020 at 05:02:49PM +0100, Bertrand Marquis wrote:
> Fix gcc10 compilation warning about uninitialized variable by setting
> it to 0.
>
> Signed-off-by: Bertrand Marquis
Acked-by: Wei Liu
On Mon, Oct 05, 2020 at 05:02:48PM +0100, Bertrand Marquis wrote:
> Use memcpy in getBridge to prevent gcc warnings about truncated
> strings. We know that we might truncate it, so the gcc warning
> here is wrong.
> Revert previous change changing buffer sizes as bigger buffers
> are not needed.
>
flight 155434 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155434/
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
Use memcpy in getBridge to prevent gcc warnings about truncated
strings. We know that we might truncate it, so the gcc warning
here is wrong.
Revert previous change changing buffer sizes as bigger buffers
are not needed.
Signed-off-by: Bertrand Marquis
---
tools/libs/stat/xenstat_linux.c | 9
Fix gcc10 compilation warning about uninitialized variable by setting
it to 0.
Signed-off-by: Bertrand Marquis
---
tools/libxl/libxl_mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
index e52a9624ea..c739d00f39 100644
Solve various issues in tools when compiling using a gcc version 10.0 or
greater.
Bertrand Marquis (2):
tools: use memcpy instead of strncpy in getBridge
tool/libx: Fix libxenlight gcc warning
tools/libs/stat/xenstat_linux.c | 9 +++--
tools/libxl/libxl_mem.c | 2 +-
2 files
> -Original Message-
> From: Julien Grall
> Sent: 05 October 2020 15:42
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Andrew Cooper
> ; Roger Pau Monné ; Wei Liu
>
> Subject: RE: [EXTERNAL] [PATCH] ioreq: cope with server disappearing while
Hi Paul,
On 05/10/2020 15:08, Paul Durrant wrote:
From: Paul Durrant
Currently, in the event of an ioreq server being destroyed while I/O is
pending in the attached emulator, it is possible that hvm_wait_for_io() will
dereference a pointer to a 'struct hvm_ioreq_vcpu' or the ioreq server's
> -Original Message-
> From: Andrew Cooper
> Sent: 05 October 2020 15:30
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Julien Grall ; Jan
> Beulich
> ; Roger Pau Monné ; Wei Liu
>
> Subject: RE: [EXTERNAL] [PATCH] ioreq: cope with server disappearing while
On 05/10/2020 15:08, Paul Durrant wrote:
> From: Paul Durrant
>
> Currently, in the event of an ioreq server being destroyed while I/O is
> pending in the attached emulator, it is possible that hvm_wait_for_io() will
> dereference a pointer to a 'struct hvm_ioreq_vcpu' or the ioreq server's
>
flight 155417 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155417/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12
From: Paul Durrant
Currently, in the event of an ioreq server being destroyed while I/O is
pending in the attached emulator, it is possible that hvm_wait_for_io() will
dereference a pointer to a 'struct hvm_ioreq_vcpu' or the ioreq server's
shared page after it has been freed.
This will only
On 01/10/2020 15:50, George Dunlap wrote:
>>> Signed-off-by: George Dunlap
>>> ---
>>>
>>> CC: Ian Jackson
>>> CC: Wei Liu
>>> CC: Andrew Cooper
>>> CC: Jan Beulich
>>> CC: Stefano Stabellini
>>> CC: Julien Grall
>>> CC: Rich Persaud
>>> CC: Bertrand Marquis
>>> ---
>>> docs/index.rst
Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
address conversion.
In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
to gfn by virt_to_gfn() macro. However, since the virt_to_gfn(v)
assumes the given virtual address is in contiguous kernel memory
area, it can not
For simplicity between various configuration, Xen always uses shadow stack
mappings (Read-only + Dirty) for the guard page, irrespective of whether
CET-SS is enabled.
memguard_guard_stack() writes shadow stack tokens with plain writes. This is
necessary to configure the BSP shadow stack
Whenever we move pages between freelists via move_to_free_list()/
move_freepages_block(), we don't actually touch the pages:
1. Page isolation doesn't actually touch the pages, it simply isolates
pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
When undoing isolation, we
__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.
This change affects two users:
- free page reporting
- page
__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. Deferred memory onlining in memory-ballooning-like mechanisms
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.
Reviewed-by: Wei Yang
Acked-by: Michal Hocko
Cc: Andrew Morton
Cc: Alexander Duyck
Cc: Mel Gorman
Cc: Michal
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().
Reviewed-by: Alexander Duyck
Reviewed-by: Vlastimil Babka
Reviewed-by: Oscar Salvador
Reviewed-by: Wei Yang
Reviewed-by: Pankaj Gupta
Acked-by:
When adding separate memory blocks via add_memory*() and onlining them
immediately, the metadata (especially the memmap) of the next block will be
placed onto one of the just added+onlined block. This creates a chain
of unmovable allocations: If the last memory block cannot get
offlined+removed()
On 01/10/2020 12:00, Roger Pau Monné wrote:
> On Wed, Sep 30, 2020 at 02:42:47PM +0100, Andrew Cooper wrote:
>> Previously, migration was reordered so the CPUID data was available before
>> register state. nestedhvm_enabled() has recently been made accurate for the
>> entire lifetime of the
Paolo Bonzini writes:
> On 05/10/20 10:01, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>
>>> Reduce the machine code pulled into qemu-storage-daemon.
>> I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and
>> Juan for PATCH 5. David already ACKed.
>>
>>
On 24/09/2020 14:10, Paul Durrant wrote:
> diff --git a/tools/misc/xen-domctx.c b/tools/misc/xen-domctx.c
> index 243325dfce..6ead7ea89d 100644
> --- a/tools/misc/xen-domctx.c
> +++ b/tools/misc/xen-domctx.c
> @@ -31,6 +31,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> -Original Message-
> From: Andrew Cooper
> Sent: 05 October 2020 11:09
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; George Dunlap
> ; Ian Jackson
> ; Jan Beulich ; Julien Grall
> ; Stefano
> Stabellini ; Wei Liu ; Marek
> Marczykowski-Górecki
>
> Subject:
On 24/09/2020 14:10, Paul Durrant wrote:
> From: Paul Durrant
>
> A new 'domain context' framework was recently introduced to facilitate
> transfer of state for both PV and HVM guests. Hence this patch mandates the
> presence of a new DOMAIN_CONTEXT record in version 4 of the libxc migration
>
From: Paul Durrant
This series introduces a pool of memory analogous to the shadow/HAP pool,
accounted to the guest domain, from which IOMMU page-tables are allocated.
Paul Durrant (5):
libxl: remove separate calculation of IOMMU memory overhead
iommu / domctl: introduce
From: Paul Durrant
... sub-operation of XEN_DOMCTL_iommu_ctl.
This patch adds a new sub-operation into the domctl. The code in iommu_ctl()
is extended to call a new arch-specific iommu_set_allocation() function which
will be called with the IOMMU page-table overhead (in 4k pages) in response
to
From: Paul Durrant
This patch, in a way analogous to HAP page allocation, creates a pool of
pages for use as IOMMU page-tables when the size of that pool is configured
by a call to iommu_set_allocation(). That call occurs when the tool-stack
has calculates the size of the pool and issues the
From: Paul Durrant
When using 'shared_pt' mode the IOMMU is using the EPT PTEs. In 'sync_pt'
mode these PTEs are instead replicated for the IOMMU to use. Hence, it is
fairly clear that the memory overhead in this mode is essentially another
copy of the P2M.
This patch removes the independent
From: Paul Durrant
A subsequent patch will introduce code to apply a cap to memory used for
IOMMU page-tables for a domain. This patch simply introduces the boilerplate
for the new domctl.
The implementation of new sub-operations of the new domctl will be added to
iommu_ctl() and hence, whilst
From: Paul Durrant
Set these flags prior to the calls to arch_iommu_domain_init() and the
implementation init() method. There is no reason to hide this information from
those functions and the value of 'hap_pt_share' will be needed by a
modification to arch_iommu_domain_init() made in a
flight 155402 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155402/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 154601
test-amd64-i386-xl-pvshim12
> -Original Message-
> From: Andrew Cooper
> Sent: 02 October 2020 22:58
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Julien Grall ;
> Daniel De Graaf
> ; Ian Jackson ; Wei Liu
> ; George Dunlap
> ; Jan Beulich ; Stefano
> Stabellini
>
> Subject: RE:
> -Original Message-
> From: Andrew Cooper
> Sent: 02 October 2020 23:40
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Ian Jackson
> ; Wei Liu
>
> Subject: RE: [EXTERNAL] [PATCH v9 3/8] tools/misc: add xen-domctx to present
> domain context
>
> CAUTION:
> -Original Message-
> From: Andrew Cooper
> Sent: 02 October 2020 23:42
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; George Dunlap
> ; Ian Jackson
> ; Jan Beulich ; Julien Grall
> ; Stefano
> Stabellini ; Wei Liu
> Subject: RE: [EXTERNAL] [PATCH v9 4/8]
On 05.10.20 10:20, Mel Gorman wrote:
> On Mon, Oct 05, 2020 at 08:56:48AM +0200, Michal Hocko wrote:
>> On Fri 02-10-20 17:20:09, David Hildenbrand wrote:
>>> 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
OP-TEE mediator tracks cookie value for a last buffer which
was requested by OP-TEE. This tracked value serves one important
purpose: if OP-TEE wants to request another buffer, we know
that it finished importing previous one and we can free page list
associated with it.
Also, we had false premise
--
Tested-by: Bertrand Marquis
Work on Yocto Gategarth (including qemu and tools compilation).
Cheers
Bertrand
> On 2 Oct 2020, at 15:22, Juergen Gross wrote:
>
> The rework of the Xen library build introduced creating some additional
> symbolic links during the build process.
>
> This
On 05/10/20 10:01, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> Reduce the machine code pulled into qemu-storage-daemon.
> I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and
> Juan for PATCH 5. David already ACKed.
>
> Can do the pull request.
>
If it
--
Acked-by: Christian Lindig
From: Edwin Török
Sent: 02 October 2020 17:06
To: xen-devel@lists.xenproject.org
Cc: Edwin Torok; Christian Lindig; David Scott; Ian Jackson; Wei Liu
Subject: [PATCH v1 1/1] tools/ocaml/xenstored: drop the creation of the RO
--
Acked-by: Christian Lindig
From: Juergen Gross
Sent: 02 October 2020 15:22
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross; Andrew Cooper; George Dunlap; Ian Jackson; Jan Beulich;
Julien Grall; Stefano Stabellini; Wei Liu; Samuel Thibault;
--
Acked-by: Christian Lindig
From: Andrew Cooper
Sent: 01 October 2020 12:02
To: Jan Beulich
Cc: Xen-devel; Roger Pau Monne; Wei Liu; Ian Jackson; Christian Lindig; Edwin
Torok; Rob Hoes
Subject: Re: [PATCH 3/8] xen/domctl: Introduce and use
On Mon, Oct 05, 2020 at 08:56:48AM +0200, Michal Hocko wrote:
> On Fri 02-10-20 17:20:09, David Hildenbrand wrote:
> > 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
> > >>
> -Original Message-
> From: Andrew Cooper
> Sent: 02 October 2020 22:20
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Julien Grall ; Jan
> Beulich
> ; George Dunlap ; Ian Jackson
> ; Stefano Stabellini ; Wei
> Liu ;
> Volodymyr Babchuk ; Roger Pau Monné
>
Philippe Mathieu-Daudé writes:
> Reduce the machine code pulled into qemu-storage-daemon.
I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and
Juan for PATCH 5. David already ACKed.
Can do the pull request.
On Fri 02-10-20 17:20:09, David Hildenbrand wrote:
> 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.
> >>
55 matches
Mail list logo
