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
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
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
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
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
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
> 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,
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: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
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
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
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
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:
> 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
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
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
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
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
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
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:
> 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.
>
>
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
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
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
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
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
>
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
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
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
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
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
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
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
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
> 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
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
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
> 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
> 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
> 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
>
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
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
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
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
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 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
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
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
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
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
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
>>> 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.
>
>
>>> 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:
> 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
>>> 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
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
>>> 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
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(-)
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
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
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
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
>>> 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
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 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
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
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 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 '=',
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
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
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 '>sh_info->flags' to 'test_bit()' 32
vs 64.
drivers/pci/xen-pcifront.c
105 static
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
Hi Xen devs,
I get the following static checker warning:
drivers/pci/xen-pcifront.c:107 schedule_pcifront_aer_op()
warn: passing casted pointer '>sh_info->flags' to 'test_bit()' 32
vs 64.
drivers/pci/xen-pcifront.c
105 static inline void schedule_pcifront_aer_op(struct
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
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
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
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(),
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
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:
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,
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
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
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
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
>>> 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
> +++
>>> 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 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 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
>>> 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
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:
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
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
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
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:
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.
>
>
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
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
flight 138368 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138368/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
>>> On 21.06.19 at 16:20, wrote:
> On 21/06/2019 15:00, Jan Beulich wrote:
>>> On 15/03/2019 11:06, Jan Beulich wrote:
@@ -138,6 +141,26 @@ static bool simd_check_avx512vbmi_vl(voi
return cpu_has_avx512_vbmi && cpu_has_avx512vl;
}
+static bool
99 matches
Mail list logo
