On Mon, Jun 24, 2019 at 11:47:09AM -0700, Stefano Stabellini wrote:
> + xen-devel
>
> On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> > Hi all,
> >
> > I might have found a bug with PCI passthrough to a Linux HVM guest on
> > x86 with Xen 4.12. It is not easy for me to get access, and especially
On Tue, Jun 25, 2019 at 01:09:22AM +, Johnson, Ethan wrote:
> On 6/20/19 7:01 PM, Andrew Cooper wrote:
> > Xen itself doesn't use autoconf, and needs a bit of extra help getting
> > its options in order. There is an extra clang=y variable which you need
> > to pass.
> >
> > xen.git$ make -C xe
Ping,
Any thoughts on this matter are appreciated.
Thanks,
Alex
On 07.06.2019 13:55, Alexandru Stefan ISAILA wrote:
> The patch adds a new lib xc function (xc_altp2m_get_vcpu_p2m_idx) that
> uses a new hvmop (HVMOP_altp2m_get_p2m_idx) to get the active altp2m
> index from a given vcpu.
>
> Sign
Are there any thoughts on this patch?
Thanks,
Alex
On 18.06.2019 14:54, Alexandru Stefan ISAILA wrote:
> At the moment the IOMMU flags are not used in p2m-pt and could be used
> on other application.
>
> This patch aims to clean the use of IOMMU flags on the AMD p2m side.
>
> Signed-off-by: Ale
On Mon, Jun 24, 2019 at 01:24:02PM +0200, Daniel Kiper wrote:
> On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrote:
> > >>> On 19.06.19 at 17:06, wrote:
> > > On Wed, Jun 19, 2019 at 06:57:05AM -0600, Jan Beulich wrote:
> > >> >>> On 19.06.19 at 13:02, wrote:
> > >> > If the hypervisor h
Gentle ping.
I'd really like to have that in 5.2 in order to avoid the regression
introduced with 5.2-rc1.
Juergen
On 20.06.19 18:08, Juergen Gross wrote:
Commit 0e56acae4b4dd4a9 ("mm: initialize MAX_ORDER_NR_PAGES at a time
instead of doing larger sections") is causing a regression on some
s
HiStefano,
On 25/06/2019 00:59, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Julien Grall wrote:
Hi,
On 6/24/19 9:17 PM, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 24/06/2019 19:27, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Stefano Stabellini w
Hi Stefano,
On 25/06/2019 01:02, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 6/24/19 9:23 PM, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Julien Grall wrote:
Hi,
On 24/06/2019 19:03, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Lars Kurth wrote:
I
>>> On 25.06.19 at 10:10, wrote:
> On Mon, Jun 24, 2019 at 01:24:02PM +0200, Daniel Kiper wrote:
>> On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrote:
>> > >>> On 19.06.19 at 17:06, wrote:
>> > > On Wed, Jun 19, 2019 at 06:57:05AM -0600, Jan Beulich wrote:
>> > >> >>> On 19.06.19 at 13:
>>> On 24.06.19 at 18:24, wrote:
>> else if ( (node = next_node(node, nodemask)) >= MAX_NUMNODES )
>> node = first_node(nodemask);
>
> On x86, MAX_NUMNODES is 64, and this part of get_free_buddy() loops over
> nodes {0..63}. next_node() expands to find_next_bit(..., node+1) which
> passes of
>>> On 24.06.19 at 20:01, wrote:
> This patch hides the issue identified in the "UBSAN report in find_next_bit()"
> so probably doesn't want applying until that is resolved.
It does so on systems with less than 64 nodes, afaict.
> A lower overhead option would be to do:
>
> nodes_and(nodemask,
>>> On 24.06.19 at 20:25, wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -138,7 +138,10 @@ $(filter-out %.init.o $(nocov-y),$(obj-y) $(obj-bin-y)
> $(extra-y)): CFLAGS += $(
> endif
>
> ifeq ($(CONFIG_UBSAN),y)
> -$(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)):
>
>>> On 24.06.19 at 12:17, wrote:
> This fixes the UBSAN build for GCC 8 and later. The sanitiser checks for
> passing 0 to the ctz()/clz() builtins.
>
> Signed-off-by: Andrew Cooper
Fundamentally
Acked-by: Jan Beulich
However,
> --- a/xen/common/ubsan/ubsan.c
> +++ b/xen/common/ubsan/ubsan.
Hi Andrew,
On 24/06/2019 13:03, Andrew Cooper wrote:
On 24/06/2019 12:09, Julien Grall wrote:
(+ GSOC mentors and Andre)
Hi Denis,
Thank you for the patch.
First of all, may I ask to CC the other mentors?
On 6/21/19 9:02 PM, Denis Obrezkov wrote:
This function allows xen to bring secondary
Hi Andrew,
On 24/06/2019 17:24, Andrew Cooper wrote:
ARM64's find_next_bit() explicitly copes with offset >= size, and while
I don't speak ARM asm well enough to work out whether
_find_first_bit_le() copes with offset == size, the vgic.c code
definitely expects it to function in this way.
I lo
Hi Jan,
On 25/06/2019 10:38, Jan Beulich wrote:
On 24.06.19 at 18:24, wrote:
ARM64's find_next_bit() explicitly copes with offset >= size, and while
I don't speak ARM asm well enough to work out whether
_find_first_bit_le() copes with offset == size, the vgic.c code
definitely expects it to fu
Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> > Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions -
> > FAIL"):
> > > These all have `qemut' in common.
...
> I'm tryi
On Tue, Jun 25, 2019 at 03:18:14AM -0600, Jan Beulich wrote:
> >>> On 25.06.19 at 10:10, wrote:
> > On Mon, Jun 24, 2019 at 01:24:02PM +0200, Daniel Kiper wrote:
> >> On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrote:
> >> > >>> On 19.06.19 at 17:06, wrote:
> >> > > On Wed, Jun 19, 2019
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc:
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such introduce the
'nopv' parameter that will do it
PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.
In order for nopv parameter to take effect for HVM guest, we need to
distinguish between PVH and HVM guest early in hypervisor detection
code. By moving the detection of PVH in xen_platform_hvm(),
xe
flight 138376 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138376/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 137381
test-amd64-i386-xl-qemut-ws16-am
On 25/06/2019, 10:03, "Julien Grall" wrote:
>>> The point here is that we can be flexible and creative about the way to
>>> maintain the docs on xen.git. But as a technology is certainly better
>>> than the wiki: we don't have to keep them all up-to-date with the code,
>>> but
On 24.06.19 14:02, Zhenzhong Duan wrote:
PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.
In order for nopv parameter to take effect for HVM guest, we need to
distinguish between PVH and HVM guest early in hypervisor detection
code. By moving the
Hi Xen devs,
I get the following static checker warning:
drivers/pci/xen-pcifront.c:107 schedule_pcifront_aer_op()
warn: passing casted pointer '&pdev->sh_info->flags' to 'test_bit()' 32
vs 64.
drivers/pci/xen-pcifront.c
105 static inline void schedule_pcifront_aer_op(struct
On Tue, Jun 25, 2019 at 01:08:49PM +0200, Roger Pau Monné wrote:
> On Tue, Jun 25, 2019 at 03:18:14AM -0600, Jan Beulich wrote:
> > >>> On 25.06.19 at 10:10, wrote:
> > > On Mon, Jun 24, 2019 at 01:24:02PM +0200, Daniel Kiper wrote:
> > >> On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrot
On 25.06.19 14:31, Dan Carpenter wrote:
Hi Xen devs,
I get the following static checker warning:
drivers/pci/xen-pcifront.c:107 schedule_pcifront_aer_op()
warn: passing casted pointer '&pdev->sh_info->flags' to 'test_bit()' 32
vs 64.
drivers/pci/xen-pcifront.c
105 static
Currently the names of the build toolchain binaries are hardcoded in
StdGNU.mk, and the values from the environment are ignored.
Switch StdGNU.mk to use '?=' instead of '=', so that values from the
environment are used if present, else default to the values provided
by the config file.
This chang
On 25/06/2019 14:39, Roger Pau Monne wrote:
> Currently the names of the build toolchain binaries are hardcoded in
> StdGNU.mk, and the values from the environment are ignored.
>
> Switch StdGNU.mk to use '?=' instead of '=', so that values from the
> environment are used if present, else default t
On Tue, Jun 25, 2019 at 02:41:09PM +0100, Andrew Cooper wrote:
> On 25/06/2019 14:39, Roger Pau Monne wrote:
> > Currently the names of the build toolchain binaries are hardcoded in
> > StdGNU.mk, and the values from the environment are ignored.
> >
> > Switch StdGNU.mk to use '?=' instead of '=',
Roger Pau Monne writes ("[PATCH] config: don't hardcode toolchain binaries"):
> Currently the names of the build toolchain binaries are hardcoded in
> StdGNU.mk, and the values from the environment are ignored.
>
> Switch StdGNU.mk to use '?=' instead of '=', so that values from the
> environment
On 25/06/2019 13:15, Lars Kurth wrote:
> On 25/06/2019, 10:03, "Julien Grall" wrote:
>
> >>> The point here is that we can be flexible and creative about the way
> to
> >>> maintain the docs on xen.git. But as a technology is certainly better
> >>> than the wiki: we don't have to kee
>>> On 25.06.19 at 13:08, wrote:
> Sorry for not being clear. By remove I mean `git rm
> xen/arch/x86/efi/relocs-dummy.S` and fix the build, like the diff
> appended below.
>
> Is there any reason we should keep the dummy .reloc in the ELF
> output?
Yes, there is. And yes, I was afraid you'd mea
Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> > Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions -
> > FAIL"):
> > > Ian Jackson writes ("Re: [xen-4.6-testing test]
>>> On 25.06.19 at 14:48, wrote:
> On Tue, Jun 25, 2019 at 01:08:49PM +0200, Roger Pau Monné wrote:
>> Sorry for not being clear. By remove I mean `git rm
>> xen/arch/x86/efi/relocs-dummy.S` and fix the build, like the diff
>> appended below.
>
> The chunk below will not work because relocs-dummy
This series supersedes the single "page-alloc: Clamp get_free_buddy() to
online nodes" patch, and performs some preparatory cleanup.
Andrew Cooper (3):
page-alloc: Rename the first_node local variable
nodemask: Remove implicit addressof from the API
page-alloc: Clamp get_free_buddy() to onli
first_node is the name of a local variable, and part of the nodemask API. The
only reason this compiles is because the nodemask API is implemented as a
macro rather than an inline function.
It is confusing to read, and breaks when the nodemask API is cleaned up.
Rename the local variable to just
d->node_affinity defaults to NODE_MASK_ALL which has bits set outside of
node_online_map. This in turn causes the loop in get_free_buddy() to waste
effort iterating over offline nodes.
Always clamp d->node_affinity to node_online_map when in use.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
The nodemask API differs from the cpumask API because each wrapper to bitmap
operations is further wrapped by a macro which takes the address of the
nodemask objects.
This results in code which is slightly confusing to read as it doesn't follow
C's calling conventions, and prohibits the use of sli
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: George Dunlap
---
xen/arch/x86/numa.c | 4 +---
xen/common/page_alloc.c | 7 ++-
2 files changed, 3 insertions(+), 8 deletions(-)
diff
>>> On 25.06.19 at 16:12, wrote:
> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
>> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
>> > Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions -
>> > FAIL"):
>> > > Ian Jack
flight 138482 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138482/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
>>> On 25.06.19 at 16:43, wrote:
> first_node is the name of a local variable, and part of the nodemask API. The
> only reason this compiles is because the nodemask API is implemented as a
> macro rather than an inline function.
>
> It is confusing to read, and breaks when the nodemask API is cl
>>> On 25.06.19 at 16:43, wrote:
> The nodemask API differs from the cpumask API because each wrapper to bitmap
> operations is further wrapped by a macro which takes the address of the
> nodemask objects.
>
> This results in code which is slightly confusing to read as it doesn't follow
> C's cal
>>> On 25.06.19 at 16:58, wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 25.06.19 at 16:43, wrote:
> d->node_affinity defaults to NODE_MASK_ALL which has bits set outside of
> node_online_map. This in turn causes the loop in get_free_buddy() to waste
> effort iterating over offline nodes.
>
> Always clamp d->node_affinity to node_online_map when in use.
>
> S
Jan Beulich writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> I've taken a look. The guests now triple fault during BIOS initialization:
Thanks. Hrm.
> I wouldn't be surprised if the rombios build is broken - did you happen
> to compare those binaries? Otoh I can't seem to spot
On 25/06/2019 16:51, Jan Beulich wrote:
On 25.06.19 at 16:43, wrote:
>> d->node_affinity defaults to NODE_MASK_ALL which has bits set outside of
>> node_online_map. This in turn causes the loop in get_free_buddy() to waste
>> effort iterating over offline nodes.
>>
>> Always clamp d->node_af
flight 138485 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
On 25/06/2019, 14:47, "Andrew Cooper" wrote:
On 25/06/2019 13:15, Lars Kurth wrote:
> On 25/06/2019, 10:03, "Julien Grall" wrote:
>
> >>> The point here is that we can be flexible and creative about the
way to
> >>> maintain the docs on xen.git. But as a technolog
Hi all:
please add your agenda items. I had only ONE series which was highlighted as
needing attention from others. Is this seriously the only one?
Regards
Lars
On 21/06/2019, 16:45, "Lars Kurth" wrote:
Hi all,
Please propose topics by either editing the running agenda documen
flight 138386 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
test-amd64-i386-qem
On 25/06/2019 17:34, Lars Kurth wrote:
>
> On 25/06/2019, 14:47, "Andrew Cooper" wrote:
>
> On 25/06/2019 13:15, Lars Kurth wrote:
> > On 25/06/2019, 10:03, "Julien Grall" wrote:
> >
> > >>> The point here is that we can be flexible and creative about
> the way to
> >
flight 138489 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138489/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
flight 138392 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138392/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf be5903ad1e244cbb0930161fb361ed0b699c4cb8
baseline version:
ovmf 719a684d7df1b5b5627f4
flight 138493 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138493/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
flight 138388 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138388/
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-libvirt-xsm 13 migrat
> On Jun 25, 2019, at 12:34, Lars Kurth wrote:
>
>
>
> On 25/06/2019, 14:47, "Andrew Cooper" wrote:
>
>>On 25/06/2019 13:15, Lars Kurth wrote:
>> On 25/06/2019, 10:03, "Julien Grall" wrote:
>>
> The point here is that we can be flexible and creative about the way to
> maintai
> On Jun 25, 2019, at 12:34, Lars Kurth wrote:
>
> On 25/06/2019, 14:47, "Andrew Cooper" wrote:
>
>> On 25/06/2019 13:15, Lars Kurth wrote:
>> On 25/06/2019, 10:03, "Julien Grall" wrote:
>>
> The point here is that we can be flexible and creative about the way to
> maintain the doc
> On Jun 25, 2019, at 12:36, Lars Kurth wrote:
>
> Hi all:
> please add your agenda items. I had only ONE series which was highlighted as
> needing attention from others. Is this seriously the only one?
Proposed agenda item: in the absence of Jira tickets, would it be useful to
have a list (e.
flight 138497 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
Hi Rich,
On 6/25/19 8:38 PM, Rich Persaud wrote:
On Jun 25, 2019, at 12:36, Lars Kurth wrote:
Hi all:
please add your agenda items. I had only ONE series which was highlighted as
needing attention from others. Is this seriously the only one?
Proposed agenda item: in the absence of Jira tick
> On Jun 25, 2019, at 16:17, Julien Grall wrote:
>
> Hi Rich,
>
> On 6/25/19 8:38 PM, Rich Persaud wrote:
>>> On Jun 25, 2019, at 12:36, Lars Kurth wrote:
>>>
>>> Hi all:
>>> please add your agenda items. I had only ONE series which was highlighted
>>> as needing attention from others. Is thi
flight 138501 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138501/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
On Tue, 25 Jun 2019, Julien Grall wrote:
> > > > The point here is that we can be flexible and creative about the way to
> > > > maintain the docs on xen.git. But as a technology is certainly better
> > > > than the wiki: we don't have to keep them all up-to-date with the code,
> > > > but at least
flight 138505 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
Hi Stefano,
On 6/25/19 10:18 PM, Stefano Stabellini wrote:
On Tue, 25 Jun 2019, Julien Grall wrote:
The point here is that we can be flexible and creative about the way to
maintain the docs on xen.git. But as a technology is certainly better
than the wiki: we don't have to keep them all up-to-d
On Tue, 25 Jun 2019, Roger Pau Monné wrote:
> On Mon, Jun 24, 2019 at 11:47:09AM -0700, Stefano Stabellini wrote:
> > + xen-devel
> >
> > On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> > > Hi all,
> > >
> > > I might have found a bug with PCI passthrough to a Linux HVM guest on
> > > x86 with X
On Mon, 10 Jun 2019, Julien Grall wrote:
> putn() and puts() are two subroutines. Add ENDPROC for the benefits of
> static analysis tools and the reader.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/arm64/head.S | 2 ++
> 1 file changed, 2 insertions(+
On Mon, 10 Jun 2019, Julien Grall wrote:
>> The current implementation of the macro PRINT will clobber x30/lr. This
> means the user should save lr if it cares about it.
By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
expression.
Reviewed-by: Stefano Stabellini
> Follow-up patch
On Mon, 10 Jun 2019, Julien Grall wrote:
> Anything executed after the label common_start can be executed on all
> CPUs. However most of the instructions executed between the label
> common_start and init_uart are not executed on the boot CPU.
>
> The only instructions executed are to lookup the C
On Tue, 25 Jun 2019, Stefano Stabellini wrote:
> On Mon, 10 Jun 2019, Julien Grall wrote:
> >> The current implementation of the macro PRINT will clobber x30/lr. This
> > means the user should save lr if it cares about it.
>
> By x30/lr, do you mean x0-x3 and lr? I would prefer a clearer
> expres
On Mon, 10 Jun 2019, Julien Grall wrote:
> After the recent rework, the CPUID is only used at the very beginning of
> the secondary CPUs boot path. So there is no need to "reserve" x24 for
> he CPUID.
If you are going to resend the series it would probably make sense to
fold it in the previous pat
On Mon, 10 Jun 2019, Julien Grall wrote:
> At the moment, the user should save x30/lr if it cares about it.
>
> Follow-up patches will introduce more use of putn in place where lr
> should be preserved.
>
> Furthermore, any user of putn should also move the value to register x0
> if it was stored
flight 138510 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
On Mon, 10 Jun 2019, Julien Grall wrote:
> A branch in the success case can be avoided by inverting the branch
> condition. At the same time, remove a pointless comment as Xen can only
> run at EL2.
>
> Lastly, document the behavior and the main registers usage within the
> function.
>
> Signed-o
On Mon, 10 Jun 2019, Julien Grall wrote:
> Adjust the coding style used in the comments within cpu_init(). Take the
> opportunity to alter the early print to match the function name.
>
> Lastly, document the behavior and the main registers usage within the
> function.
>
> Signed-off-by: Julien Gr
On Mon, 10 Jun 2019, Julien Grall wrote:
> The boot code is currently quite difficult to go through because of the
> lack of documentation and a number of indirection to avoid executing
> some path in either the boot CPU or secondary CPUs.
>
> In an attempt to make the boot code easier to follow,
On Mon, 10 Jun 2019, Julien Grall wrote:
> On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
> zeroed once at boot. So the call in the secondary CPUs path can be
> removed. It also means that x26 does not need to set and is now only
> used by the boot CPU.
>
> Lastly, documen
On Mon, 10 Jun 2019, Julien Grall wrote:
> Adjust the coding style used in the comments within create_pages_tables()
>
> Lastly, document the behavior and the main registers usage within the
> function. Note that x25 is now only used within the function, so it does
> not need to be part of the com
On Mon, 10 Jun 2019, Julien Grall wrote:
> Document the behavior and the main registers usage within enable_mmu().
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/arm64/head.S | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/hea
On Mon, 10 Jun 2019, Julien Grall wrote:
> The assembly switch to the runtime PT is only necessary for the
> secondary CPUs. So move the code in the secondary CPUs path.
>
> While this is definitely not compliant with the Arm Arm as we are
> switching between two differents set of page-tables with
flight 138517 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138517/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
flight 138419 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138419/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd fc870a6df90c3876ec348720e21e74beb8b70d92
baseline version:
freebsd 5b2895d685c
> On Jun 25, 2019, at 2:29 PM, Dave Hansen wrote:
>
> On 6/12/19 11:48 PM, Nadav Amit wrote:
>> To improve TLB shootdown performance, flush the remote and local TLBs
>> concurrently. Introduce flush_tlb_multi() that does so. The current
>> flush_tlb_others() interface is kept, since paravirtual i
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 1b
flight 138399 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138399/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 7 xen-boot fail in 138285 pass in 138399
test-armhf-armhf-xl-vhd 10 debi
flight 138394 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138394/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 138023
test-amd64-amd64-xl-qemuu-win7-amd64 17
flight 138519 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138519/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
build-arm64-
> On Jun 25, 2019, at 8:00 PM, Dave Hansen wrote:
>
> On 6/25/19 7:35 PM, Nadav Amit wrote:
const struct flush_tlb_info *f = info;
+ enum tlb_flush_reason reason;
+
+ reason = (f->mm == NULL) ? TLB_LOCAL_SHOOTDOWN : TLB_LOCAL_MM_SHOOTDOWN;
>>>
>>> Should we just add the "re
On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote:
>
> To improve TLB shootdown performance, flush the remote and local TLBs
> concurrently. Introduce flush_tlb_multi() that does so. The current
> flush_tlb_others() interface is kept, since paravirtual interfaces need
> to be adapted first before
> On Jun 25, 2019, at 8:36 PM, Andy Lutomirski wrote:
>
> On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote:
>> To improve TLB shootdown performance, flush the remote and local TLBs
>> concurrently. Introduce flush_tlb_multi() that does so. The current
>> flush_tlb_others() interface is kept, si
On Tue, Jun 25, 2019 at 8:48 PM Nadav Amit wrote:
>
> > On Jun 25, 2019, at 8:36 PM, Andy Lutomirski wrote:
> >
> > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit wrote:
> >> To improve TLB shootdown performance, flush the remote and local TLBs
> >> concurrently. Introduce flush_tlb_multi() that do
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced:
On 6/25/19 7:35 PM, Nadav Amit wrote:
>>> const struct flush_tlb_info *f = info;
>>> + enum tlb_flush_reason reason;
>>> +
>>> + reason = (f->mm == NULL) ? TLB_LOCAL_SHOOTDOWN : TLB_LOCAL_MM_SHOOTDOWN;
>>
>> Should we just add the "reason" to flush_tlb_info? It's OK-ish to imply
>> it like
On 6/12/19 11:48 PM, Nadav Amit wrote:
> To improve TLB shootdown performance, flush the remote and local TLBs
> concurrently. Introduce flush_tlb_multi() that does so. The current
> flush_tlb_others() interface is kept, since paravirtual interfaces need
> to be adapted first before it can be remov
On 26.06.19 00:10, Stefano Stabellini wrote:
On Tue, 25 Jun 2019, Juergen Gross wrote:
On 24.06.19 20:45, Stefano Stabellini wrote:
Hi all,
I might have found a bug with PCI passthrough to a Linux HVM guest on
x86 with Xen 4.12. It is not easy for me to get access, and especially
change compon
branch xen-unstable
xenbranch xen-unstable
job build-armhf
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem ch
On 24.06.19 20:47, Stefano Stabellini wrote:
+ xen-devel
On Mon, 24 Jun 2019, Stefano Stabellini wrote:
Hi all,
I might have found a bug with PCI passthrough to a Linux HVM guest on
x86 with Xen 4.12. It is not easy for me to get access, and especially
change components, on this particular sys
flight 138414 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138414/
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-pre
1 - 100 of 101 matches
Mail list logo