flight 135480 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 70 xtf/test-hvm64-xsa-278 fail REGR. vs. 130965
build-amd64-pre
flight 135478 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135478/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 134997
test-amd64-amd64-qemuu-nested-am
flight 135476 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135476/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133989
Tests which di
flight 135473 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135473/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail in 135429 REGR. vs.
134015
Tests which are
pfn_pdx_hole_setup is meant to skip the first MAX_ORDER bits, but
actually it only skips the first MAX_ORDER-1 bits. The issue was
probably introduced by bdb5439c3f, when changing to loop to start from
MAX_ORDER-1 an adjustment by 1 was needed in the call to find_next_bit()
but not done.
Fix the i
The mask calculation in init_pdx is wrong when the first bank starts at
address 0x0. The reason is that pdx_init_mask will do '0 - 1' causing an
underflow. As a result, the mask becomes 0x which is the
biggest possible mask and ends up causing a significant memory waste in
the frame
pfn_to_pdx expects an address, not a size, as a parameter. It expects
the end address, and the masks calculations compensate for any holes
between start and end. Pass the end address to pfn_to_pdx. Also remove
from the result pfn_to_pdx(start_address) because we know that we
don't need to cover any
Hi all,
This series is a small collection of PDX fixes. They are technically
independent but discovered together trying to understand the memory
waste caused by the frametable allocation on Xilinx ZynqMP.
Cheers,
Stefano
The following changes since commit dc497635d93f6672f82727ad97a55205177be2
flight 135470 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133923
Tests which did not
flight 135468 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133468
test-amd64-amd64-qemu
On Fri, 3 May 2019, Jan Beulich wrote:
> >>> On 03.05.19 at 00:25, wrote:
> > All right. Looking at the comment in pfn_pdx_hole_setup, it seems that
> > it is intending to skip the first MAX_ORDER bits, but actually it is
> > skipping the first MAX_ORDER-1 bits, if my calculations are correct.
> >
When unpausing a capped domain, the scheduler currently clears the
CSCHED_FLAG_VCPU_PARKED flag before vcpu_wake(). This, in turn, causes the
vcpu_wake to set CSCHED_PRI_TS_BOOST, resulting in an unfair credit boost. The
comment around the changed lines already states that clearing the flag should
On 3. May 2019, at 20:56, Lars Kurth
mailto:lars.kurth@gmail.com>> wrote:
On 3 May 2019, at 10:48, Dario Faggioli
mailto:dfaggi...@suse.com>> wrote:
On Fri, 2019-05-03 at 15:38 +, Eslam Elnikety wrote:
When unpausing a capped domain, the scheduler currently clears the
CSCHED_FLAG_VCP
> On 3 May 2019, at 10:48, Dario Faggioli wrote:
>
> On Fri, 2019-05-03 at 15:38 +, Eslam Elnikety wrote:
>> When unpausing a capped domain, the scheduler currently clears the
>> CSCHED_FLAG_VCPU_PARKED flag before vcpu_wake(). This, in turn,
>> causes the
>> vcpu_wake to set CSCHED_PRI_TS_
On 03/05/2019 16:59, Andrii Anisov wrote:
Hello Julien,
Hi,
On 22.04.19 19:49, Julien Grall wrote:
The function create_xen_entries may be concurrently called. So we need
to protect with a spinlock to avoid corruption the page-tables.
The question from me is why didn't we step into this
On 03/05/2019 16:58, Andrii Anisov wrote:
On 22.04.19 19:49, Julien Grall wrote:
We currently use the very long version __attribute__((__aligned(4096)))
to align page-tables. Thankfully there is a shorter version to make
IMO it is better to change `version` to `macro`. In order to specify
No functional change.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index c8bcad33..10ab65a8 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -54,7 +54,6 @@ set -e -o posi
XEN should not forward PPIs to Dom0 as it only support SPIs.
One of solution to this problem is to skip any device that
uses PPI source completely while building domain itself.
This patch goes through all the interrupt sources of device and skip it
if one of interrupt source is PPI. It fixes XEN b
No functional change.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index 10ab65a8..b41bf478 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -115,6 +115,13 @@ compute_adjusts ()
No significant functional change.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index d63e29b6..2e1d3b88 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -167,6 +167,9 @@ while [ $# -ne 0
This makes debugging it easier. No functional change with zero or one
occurrences of -D.
Signed-off-by: Ian Jackson
---
cs-adjust-flight | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/cs-adjust-flight b/cs-adjust-flight
index badabeff..cc1684b4
This may be useful for some things. For example, it will be used in
just a moment.
Signed-off-by: Ian Jackson
---
mg-execute-flight | 1 +
1 file changed, 1 insertion(+)
diff --git a/mg-execute-flight b/mg-execute-flight
index b3cdf431..391f4810 100755
--- a/mg-execute-flight
+++ b/mg-execute-
Without this they tend to be interpreted as HOSTSPECs leading to
lossage.
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-repro-setup | 4
1 file changed, 4 insertions(+)
diff --git a/mg-repro-setup b/mg-repro-setup
index 7f075f4e..dc6c5cbb 100755
--- a/mg-repro-setup
+++ b/mg-repro-se
No functional change.
Signed-off-by: Ian Jackson
---
cs-adjust-flight | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/cs-adjust-flight b/cs-adjust-flight
index ee1d917c..badabeff 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -194,10 +194,8 @@ s
On 03/05/2019 16:57, Andrii Anisov wrote:
Hello Julien,
Hi,
On 22.04.19 19:49, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for CPU0 domheap is unn
This allows a single command to repro a particular job with a variety
of different source code.
The implementation technique is:
- run the build job in a separate flight, so that it can run
with a separate task which gives its host up after the build
- do much of the heavy lifting of runva
This is obviously wrong. In fact it does not work (we bomb out in the
allocation).
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-allocate | 10 ++
1 file changed, 10 insertions(+)
diff --git a/mg-allocate b/mg-allocate
index 087b14b0..b5dc185e 100755
--- a/mg-allocate
+++ b/mg-al
Signed-off-by: Ian Jackson
---
mg-repro-setup | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index 6ed4d85e..c8bcad33 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -33,7 +33,7 @@ usage () { cat < is \`host')
OPTIONs
- -t est
It is annoying that mg-repro-flight cannot run a build for you too.
Fix this.
This is on xenbits in
https://xenbits.xen.org/git-http/people/iwj/osstest.git
xenbits.xen.org:/home/iwj/ext/osstest.git
etc. as the branch
wip.repro-flight-builds.v2
This version seems to actually work.
Ian Jacks
No functional change with existing call sites.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index b41bf478..d63e29b6 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -46,7 +46,7 @@ END
}
Sorry Just sent the wrong patch , Please ignore this.
On Fri, May 3, 2019 at 10:13 PM Amit Singh Tomar wrote:
>
> XEN should not forward PPIs to Dom0 as it only support SPIs.
> One of solution to this problem is to skip any device that
> uses PPI source completely while building domain itself.
>
On Fri, 2019-05-03 at 15:38 +, Eslam Elnikety wrote:
> When unpausing a capped domain, the scheduler currently clears the
> CSCHED_FLAG_VCPU_PARKED flag before vcpu_wake(). This, in turn,
> causes the
> vcpu_wake to set CSCHED_PRI_TS_BOOST, resulting in an unfair credit
> boost. The
> comment a
XEN should not forward PPIs to Dom0 as it only support SPIs.
One of solution to this problem is to skip any device that
uses PPI source completely while building domain itself.
This patch goes through all the interrupt sources of device and skip it
if one of interrupt source is PPI. It fixes XEN b
On Mon, Apr 29, 2019 at 05:24:39AM -0600, Jan Beulich wrote:
> desc->arch.cpu_mask reflects the actual set of target CPUs. Don't ever
> fiddle with desc->affinity itself, except to store caller requested
> values.
>
> This renders both set_native_irq_info() uses (which weren't using proper
> locki
On 03/05/2019 16:57, Andrii Anisov wrote:
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.
Thankfully today, r3 will always be zer
On 03.05.19 19:17, Julien Grall wrote:
I can offer to reshuffle the patches so this one is before #5, but not merge
them.
Good option. I like it.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists
On 03.05.19 19:10, Julien Grall wrote:
I don't understand what is your "second". Does it mean you are happy with the
idea of the patch but we should agree on the naming first?
Yes, I'm ok with the change.
Actually I like the part with HSCTLR_CLEAR as a compilation time guard.
But naming shou
Hi,
On 03/05/2019 16:56, Andrii Anisov wrote:
On 22.04.19 19:49, Julien Grall wrote:
The parameter cpuid is not used by start_xen. So remove it.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/head.S | 1 -
xen/arch/arm/arm64/head.S | 1 -
xen/arch/arm/setup.c | 3 +--
3 files ch
On 03/05/2019 16:56, Andrii Anisov wrote:
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
None of the parameters of secondary_start are actually used. So turn
secondary_start to a function with no parameters.
Also modify the assembly code to avoid setting-up the registers before
calling
On 03.05.19 19:09, Julien Grall wrote:
I don't understand what is your "second". Does it mean you are happy with the
idea of the patch but we should agree on the naming first?
Yes, right you are.
Sorry for the mess.
--
Sincerely,
Andrii Anisov.
_
Hi,
On 03/05/2019 16:56, Andrii Anisov wrote:
On 22.04.19 19:49, Julien Grall wrote:
/* HCR Hyp Configuration Register */
#define HCR_RW (_AC(1,UL)<<31) /* Register Width, ARM64 only */
Resolution of the dispute with Jan about [PATCH 01/20] is required first.
I don't understan
On 03/05/2019 16:56, Andrii Anisov wrote:
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The newly introduced macro _BITUL makes the code more readable.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/processor.h | 18 +-
1 file changed, 9 insertions(+), 9 delet
On 22.04.19 19:49, Julien Grall wrote:
Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.
So the initialization of the page-tables can be done much earlier in the
boot process. The earliest setup_page_tables()
On 22.04.19 19:49, Julien Grall wrote:
We currently use the very long version __attribute__((__aligned(4096)))
to align page-tables. Thankfully there is a shorter version to make
IMO it is better to change `version` to `macro`. In order to specify it is not
a compiler specific but specific t
On 22.04.19 19:49, Julien Grall wrote:
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.
Rather than dealing with Break-Before-Make in set_fixmap, every call to
set_fixmap is paired with a call to clear_
On 22.04.19 19:49, Julien Grall wrote:
The two helpers {destroy, modify}_xen_mappings don't check that the
start is always before the end. This should never happen but if it
happens, it will result to unexpected behavior.
Catch such issues earlier on by adding an ASSERT in destroy_xen_mappings
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The function create_xen_entries may be concurrently called. So we need
to protect with a spinlock to avoid corruption the page-tables.
The question from me is why didn't we step into this issue before?
Signed-off-by: Julien Grall
---
x
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The co-processor registers MAIR0 and MAIR1 are managed by EL1. So there
are no need to initialize them during Xen boot.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
___
On 22.04.19 19:49, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables is
unnecessary.
Signed-off-by: Julien Grall
Re
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.
Thankfully today, r3 will always be zero when we care. But this is
difficult to trac
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR.
So remove the zeroing and
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for CPU0 domheap is unnecessary.
Furthermore, CPU0 page-tables are part of
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
So far, we don't init specific core initialization at boot. So remove
the comment.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing lis
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
At the moment, the earlyprintk messages are interleaved with the
instructions. This makes more difficult to read the objdump output.
Introduce a new macro to add a string in .rodata.str and use it for all
the earlyprintk messages.
Signed-off
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR_EL1.
So remove the zeroing
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The parameter cpuid is not used by start_xen. So remove it.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/head.S | 1 -
xen/arch/arm/arm64/head.S | 1 -
xen/arch/arm/setup.c | 3 +--
3 files changed, 1 insertion(+), 4 deletion
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The SCTLR_* are currently used for SCTLR/HSCTLR (arm32) and
SCTLR_EL1/SCTLR_EL2 (arm64).
The naming scheme is actually quite confusing because they may only be
defined for an archicture (or even an exception level). So it is not easy
for the
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The current value of HSCTLR_BASE for Arm64 is pretty wrong. It would
actually turn on SCTLR_EL2.nAA (bit 6) on hardware implementing
ARMv8.4-LSE.
Furthermore, the documentation of what is cleared/set in SCTLR_EL2 is
also not correct and looks
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
The newly introduced macro _BITUL makes the code more readable.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/processor.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/xen/include/asm-arm/pro
Hello Julien,
On 22.04.19 19:49, Julien Grall wrote:
None of the parameters of secondary_start are actually used. So turn
secondary_start to a function with no parameters.
Also modify the assembly code to avoid setting-up the registers before
calling secondary_start.
What is not really mandat
On Mon, Apr 29, 2019 at 05:23:49AM -0600, Jan Beulich wrote:
> Don't log a stray trailing comma. Shorten a few fields.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
> -for ( i = 0; i < action->nr_guests; i++ )
> +for ( i = 0; i < action->nr_guests; )
>
When unpausing a capped domain, the scheduler currently clears the
CSCHED_FLAG_VCPU_PARKED flag before vcpu_wake(). This, in turn, causes the
vcpu_wake to set CSCHED_PRI_TS_BOOST, resulting in an unfair credit boost. The
comment around the changed lines already states that clearing the flag should
On Fri, May 03, 2019 at 04:11:32PM +0200, Olaf Hering wrote:
> Am Fri, 3 May 2019 13:04:11 +0200
> schrieb Roger Pau Monné :
>
> > Wouldn't it be easier to leave libxl__need_xenpv_qemu alone and just
> > use the contents of the migration stream to decide whether to launch a
> > QEMU for the PV bac
On Fri, May 3, 2019 at 8:35 AM George Dunlap wrote:
>
> On 5/3/19 2:57 PM, Jan Beulich wrote:
> On 03.05.19 at 15:43, wrote:
> >> On Fri, May 3, 2019 at 2:27 AM Jan Beulich wrote:
> >>>
> >> On 03.05.19 at 00:13, wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x
On Mon, Apr 29, 2019 at 05:23:20AM -0600, Jan Beulich wrote:
> The cleanup IPI may get sent immediately before a CPU gets removed from
> the online map. In such a case the IPI would get handled on the CPU
> being offlined no earlier than in the interrupts disabled window after
> fixup_irqs()' main
There's no reason to request physically contiguous memory for those
allocations.
Reported-by: Ian Jackson
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Konrad Rzeszutek Wilk
Cc: Jens Axboe
Cc: xen-devel@lists.xenproject.org
Cc: linux-bl.
On 5/3/19 2:57 PM, Jan Beulich wrote:
On 03.05.19 at 15:43, wrote:
>> On Fri, May 3, 2019 at 2:27 AM Jan Beulich wrote:
>>>
>> On 03.05.19 at 00:13, wrote:
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -112,13 +112,48 @@ static inline void pag
On Fri, May 03, 2019 at 03:16:52PM +0100, Julien Grall wrote:
> > > diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> > > index d81f54b6b8..c075bbf546 100644
> > > --- a/xen/common/libfdt/Makefile
> > > +++ b/xen/common/libfdt/Makefile
> > > @@ -3,6 +3,7 @@ include Makefile.lib
Hi,
On 03/05/2019 14:41, Wei Liu wrote:
On Fri, May 03, 2019 at 02:35:08PM +0100, Julien Grall wrote:
Hi Wei,
On 5/3/19 12:08 PM, Wei Liu wrote:
On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
(+ Wei)
On 5/2/19 5:55 PM, Viktor Mitin wrote:
Hi Julien,
Hi,
Please find trace
On Fri, May 3, 2019 at 7:56 AM Jan Beulich wrote:
>
> >>> On 03.05.19 at 15:48, wrote:
> > On Fri, May 3, 2019 at 2:12 AM Jan Beulich wrote:
> >>
> >> >>> On 03.05.19 at 00:13, wrote:
> >> > @@ -1002,7 +989,10 @@ static int share_pages(struct domain *sd, gfn_t
> >> > sgfn, shr_handle_t sh,
> >
Am Fri, 3 May 2019 13:04:11 +0200
schrieb Roger Pau Monné :
> Wouldn't it be easier to leave libxl__need_xenpv_qemu alone and just
> use the contents of the migration stream to decide whether to launch a
> QEMU for the PV backends or not? ie: just parsing the domain config on
> the migration strea
>>> On 03.05.19 at 11:19, wrote:
> On Mon, Apr 29, 2019 at 09:40:14AM -0600, Jan Beulich wrote:
>> --- unstable.orig/xen/arch/x86/irq.c
>> +++ unstable/xen/arch/x86/irq.c
>> @@ -242,6 +242,20 @@ void destroy_irq(unsigned int irq)
>> xfree(action);
>> }
>>
>> +static void release_old_vec(s
flight 135472 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-amd64-xsm
>>> On 03.05.19 at 15:43, wrote:
> On Fri, May 3, 2019 at 2:27 AM Jan Beulich wrote:
>>
>> >>> On 03.05.19 at 00:13, wrote:
>> > --- a/xen/arch/x86/mm/mem_sharing.c
>> > +++ b/xen/arch/x86/mm/mem_sharing.c
>> > @@ -112,13 +112,48 @@ static inline void page_sharing_dispose(struct
>> > page_info
>>> On 03.05.19 at 15:48, wrote:
> On Fri, May 3, 2019 at 2:12 AM Jan Beulich wrote:
>>
>> >>> On 03.05.19 at 00:13, wrote:
>> > @@ -1002,7 +989,10 @@ static int share_pages(struct domain *sd, gfn_t
>> > sgfn, shr_handle_t sh,
>> > /* Free the client page */
>> > if(test_and_clear_bit
On Fri, May 3, 2019 at 2:12 AM Jan Beulich wrote:
>
> >>> On 03.05.19 at 00:13, wrote:
> > @@ -1002,7 +989,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
> > shr_handle_t sh,
> > /* Free the client page */
> > if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
> >
On Fri, May 3, 2019 at 2:18 AM Jan Beulich wrote:
>
> >>> On 03.05.19 at 00:13, wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -368,7 +368,9 @@ void __init arch_init_memory(void)
> >
> > efi_init_memory();
> >
> > +#ifdef CONFIG_MEM_SHARING
> > mem_sharing_init();
On Fri, May 3, 2019 at 2:27 AM Jan Beulich wrote:
>
> >>> On 03.05.19 at 00:13, wrote:
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -112,13 +112,48 @@ static inline void page_sharing_dispose(struct
> > page_info *page)
> >
> > #endif /* MEM_SHARING_AUDI
On Fri, May 03, 2019 at 02:35:08PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 5/3/19 12:08 PM, Wei Liu wrote:
> > On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
> > > (+ Wei)
> > >
> > > On 5/2/19 5:55 PM, Viktor Mitin wrote:
> > > > Hi Julien,
> > >
> > > Hi,
> > >
> > > > Plea
Hi Wei,
On 5/3/19 12:08 PM, Wei Liu wrote:
On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
(+ Wei)
On 5/2/19 5:55 PM, Viktor Mitin wrote:
Hi Julien,
Hi,
Please find trace log below:
root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA
On Thu, May 02, 2019 at 04:14:57PM +0200, Martin Schwidefsky wrote:
> On Thu, 2 May 2019 06:46:23 -0700
> Matthew Wilcox wrote:
>
> > On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
> > > Drop the pgtable_t variable from all implementation for pte_fn_t as none
> > > of
> > > t
Hi,
As stated by the documentation:
"_Xen Project downloads various dependencies at build time_"
This makes Xen a difficult project to work with in an offline environment.
Thanks to the IRC channel, I heard of the command
`make subtree-force-update-all`
(We could document this option in the wiki
Am 03.05.19 um 14:09 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote:
>> Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin:
>>> On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
Add a structure for
On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote:
> Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin:
> > On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
> > > Add a structure for the parameters of dma_buf_attach, this makes it much
> > > easier
> > > to
Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin:
On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
Add a structure for the parameters of dma_buf_attach, this makes it much easier
to add new parameters later on.
I don't understand this reasoning. What are the "new par
On Fri, May 03, 2019 at 11:42:51AM +0200, Olaf Hering wrote:
> If a domU has a qemu-xen instance attached, it is required to call qemus
> "xen-save-devices-state" method. Without it, the receiving side of a PV or
> PVH migration may be unable to lock the image:
>
> xen be: qdisk-51712: xen be: qdi
On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
> (+ Wei)
>
> On 5/2/19 5:55 PM, Viktor Mitin wrote:
> > Hi Julien,
>
> Hi,
>
> > Please find trace log below:
> >
> > root@h3ulcb:~# xencov reset
> > (XEN) Data Abort Trap. Syndrome=0x7
> > (XEN) Walking Hypervisor VA 0x361700 on CP
Adding Stefano for archaelogical reasons.
Anthony PERARD writes ("[PATCH] tools/Makefile: Fix build of QEMU, remove
--source-path"):
> Following QEMU's commit 79d77bcd36 (configure: Remove --source-path
> option), Xen's build system fails to build qemu-xen. The --source-path
> option gives redund
If a domU has a qemu-xen instance attached, it is required to call qemus
"xen-save-devices-state" method. Without it, the receiving side of a PV or
PVH migration may be unable to lock the image:
xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock
error: Failed to get "write
On Mon, Apr 29, 2019 at 09:40:14AM -0600, Jan Beulich wrote:
> The flag being set may prevent affinity changes, as these often imply
> assignment of a new vector. When there's no possible destination left
> for the IRQ, the clearing of the flag needs to happen right from
> fixup_irqs().
>
> Additi
>>> On 03.05.19 at 00:13, wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -112,13 +112,48 @@ static inline void page_sharing_dispose(struct
> page_info *page)
>
> #endif /* MEM_SHARING_AUDIT */
>
> -static inline int mem_sharing_page_lock(struct page_i
On 5/3/19 11:09 AM, Jan Beulich wrote:
On 03.05.19 at 00:54, wrote:
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Coo
>>> On 03.05.19 at 00:13, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -368,7 +368,9 @@ void __init arch_init_memory(void)
>
> efi_init_memory();
>
> +#ifdef CONFIG_MEM_SHARING
> mem_sharing_init();
> +#endif
While for domctl code and alike using #ifdef may indeed
>>> On 03.05.19 at 00:13, wrote:
> @@ -1002,7 +989,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
> shr_handle_t sh,
> /* Free the client page */
> if(test_and_clear_bit(_PGC_allocated, &cpage->count_info))
> put_page(cpage);
> -put_page(cpage);
> +
> +BUG_
>>> On 03.05.19 at 00:54, wrote:
> Receiving this register is useful for introspecting 32-bit Windows when the
> event being trapped happened while in ring3.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
>
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-amd64-xsm
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
>>> On 03.05.19 at 09:53, wrote:
> On 25.04.2019 15:54, Jan Beulich wrote:
>> It is an issue anyway that a change is
>> made without saying why the new behavior preferable over
>> the current one.
>
> So is there a way to continue with this?
Why not - I've not said I'm against, I've just asked f
On 25.04.2019 15:54, Jan Beulich wrote:
On 24.04.19 at 16:46, wrote:
>> On Wed, Apr 24, 2019 at 02:27:32PM +, Alexandru Stefan ISAILA wrote:
>>> @@ -1053,15 +1053,11 @@ static void change_type_range(struct p2m_domain
>>> *p2m,
>>>* This should be revisited later, but for now po
>>> On 03.05.19 at 00:25, wrote:
> All right. Looking at the comment in pfn_pdx_hole_setup, it seems that
> it is intending to skip the first MAX_ORDER bits, but actually it is
> skipping the first MAX_ORDER-1 bits, if my calculations are correct.
>
> MAX_ORDER is 18 on ARM which correspond to 1G
99 matches
Mail list logo
