> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, June 7, 2019 5:22 PM
>
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Kevin Tian
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, June 7, 2019 5:22 PM
>
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Kevin Tian
__
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, June 7, 2019 5:22 PM
>
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Kevin Tian
__
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, June 7, 2019 5:22 PM
>
> And fix it's only caller.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://list
flight 138571 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138571/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, June 7, 2019 5:22 PM
>
> And fix it's only caller.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Paul Durrant
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@list
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, June 27, 2019 3:02 AM
>
> From: Sergey Dyasli
>
> Otherwise hvm_set_cr0() will check the wrong CR4 bits (L1 instead of L2
> and vice-versa).
>
> Signed-off-by: Sergey Dyasli
> Reviewed-by: Andrew Cooper
Acked-by: Kevi
flight 138598 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138598/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, 26 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/26/19 9:25 PM, Stefano Stabellini wrote:
> > On Mon, 10 Jun 2019, Julien Grall wrote:
> > > The ID map may clash with other parts of the Xen virtual memory layout.
> > > At the moment, Xen is handling the clash by only creating a mapp
Writing here a summary of the follow-up discussion on IRC.
This is due to a magic memory region, not described in the device tree,
being accessed by Linux. The memory region is 0x48243400 - 0x48243400+512.
To fix problems like this one, we have the platform specific files in
xen: see the files un
On 6/25/19 16:46, Julien Grall 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:
O
flight 138562 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138562/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-examine 11 examine-serial/bootloader fail pass in 138441
Tests which did not succeed, but
flight 138594 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138594/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 138569 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138569/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 18 leak-check/check fail REGR. vs. 138461
Tests which did not suc
CC'ed other GSoC mentors
On 6/27/19 9:52 PM, Denis Obrezkov wrote:
> Hello all,
>
> I have a failure when I am trying to boot Linux with Xen on bb-x15, here
> is the log:
> https://pastebin.com/BBAFPkVU
>
> and, as Julien (cc'ed) suggested here is the DT debug information for xen:
> https://driv
flight 138548 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138548/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 138386
test-amd64-amd64-pai
Hello all,
I have a failure when I am trying to boot Linux with Xen on bb-x15, here
is the log:
https://pastebin.com/BBAFPkVU
and, as Julien (cc'ed) suggested here is the DT debug information for xen:
https://drive.google.com/open?id=15YTsCKYUTbG2i-siWezJXKWuG0H1VfQz
So, what I was able to figur
On 27/06/2019 20:41, Igor Druzhinin wrote:
> This fixes booting of old non-PV-OPS kernels which historically
> looked for OSXSAVE instead of XSAVE bit in CPUID to check whether
> XSAVE feature is enabled. If such a guest appears to be started on
> an XSAVE enabled CPU and the feature is explicitly
This fixes booting of old non-PV-OPS kernels which historically
looked for OSXSAVE instead of XSAVE bit in CPUID to check whether
XSAVE feature is enabled. If such a guest appears to be started on
an XSAVE enabled CPU and the feature is explicitly cleared in
policy, leaked OSXSAVE bit from Xen will
Hi Stefano,
On 6/27/19 7:55 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
+1:
+/*
+ * Find the second slot used. Remove the entry for the first
+ * table if the slot is not 1 (runtime Xen mapping is 2M - 4M).
+ * For slot 1, it means the
On Mon, 10 Jun 2019, Julien Grall wrote:
> The ID map may clash with other parts of the Xen virtual memory layout.
> At the moment, Xen is handling the clash by only creating a mapping to
> the runtime virtual address before enabling the MMU.
>
> The rest of the mappings (such as the fixmap) will
GCC 5 introduced -fsanitize=alignment which is enabled by default by
CONFIG_UBSAN. This trips a load of wont-fix cases in the ACPI tables and the
hypercall page and stubs writing logic.
It also causes the native Xen boot to crash before the console is set up, for
an as-yet unidentified reason (mo
flight 138593 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138593/
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-
From: Colin Ian King
Shifting the integer value 1 is evaluated using 32-bit
arithmetic and then used in an expression that expects a 64-bit
value, so there is potentially an integer overflow. Fix this
by using the BIT_ULL macro to perform the shift.
Addresses-Coverity: ("Unintentional integer ov
On 6/27/19 8:58 AM, Nicolas Belouin wrote:
> Go is doing more type check (even when using CGo), so these incorrect
> use of `unsafe.Pointer` as well as the lack of `unsafe.Pointer` for
> these calls no longer compile with recent Go versions.
>
> This does *not* break compatibility with older Go ve
flight 138558 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138558/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 137600
build-amd64
On Thu, 27 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 26/06/2019 20:30, Julien Grall wrote:
> > On 6/26/19 8:01 PM, Stefano Stabellini wrote:
> > > On Mon, 10 Jun 2019, Julien Grall wrote:
> > > > At the moment, the fixmap table is only hooked when earlyprintk is used.
> > > > This is fine
On 25.06.19 10:25, Juergen Gross wrote:
Gentle ping.
I'd really like to have that in 5.2 in order to avoid the regression
introduced with 5.2-rc1.
Adding some maintainers directly...
Juergen
Juergen
On 20.06.19 18:08, Juergen Gross wrote:
Commit 0e56acae4b4dd4a9 ("mm: initialize MAX_OR
flight 138590 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138590/
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-
In order for the CPUs to use x2APIC mode, the IOMMU(s) first need to be
switched into suitable state.
The post-AP-bringup IRQ affinity adjustment is done also for the non-
x2APIC case.
Signed-off-by: Jan Beulich
---
v2: Drop cpu_has_cx16 check. Add comment.
---
TBD: Instead of the system_state c
While for 32-bit IRTEs I think we can safely continue to assume that the
writes will translate to a single MOV, the use of CMPXCHG16B is more
heavy handed than necessary for the 128-bit form, and the flushing
didn't get done along the lines of what the specification says. Mark
entries to be updated
In order to be able to express all possible destinations we need to make
use of this non-MSI-capability based mechanism. The new IRQ controller
structure can re-use certain MSI functions, though.
For now general and PPR interrupts still share a single vector, IRQ, and
hence handler.
Signed-off-by
Early enabling (to enter x2APIC mode) requires deferring of the IRQ
setup. Code to actually do that setup in the x2APIC case will get added
subsequently.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_ini
Mapping the MMIO space and obtaining feature information needs to happen
slightly earlier, such that for x2APIC support we can set XTEn prior to
calling amd_iommu_update_ivrs_mapping_acpi() and
amd_iommu_setup_ioapic_remapping().
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/d
This is in preparation of actually enabling x2APIC mode, which requires
this wider IRTE format to be used.
A specific remark regarding the first hunk changing
amd_iommu_ioapic_update_ire(): This bypass was introduced for XSA-36,
i.e. by 94d4a1119d ("AMD,IOMMU: Clean up old entries in remapping
tab
At the same time restrict its scope to just the single source file
actually using it, and abstract accesses by introducing a union of
pointers. (A union of the actual table entries is not used to make it
impossible to [wrongly, once the 128-bit form gets added] perform
pointer arithmetic / array ac
Also introduce a field in struct amd_iommu caching the most recently
written control register. All writes should now happen exclusively from
that cached value, such that it is guaranteed to be up to date.
Take the opportunity and add further fields. Also convert a few boolean
function parameters t
This also takes care of several of the shift values wrongly having been
specified as hex rather than dec.
Take the opportunity and add further fields.
Signed-off-by: Jan Beulich
---
v2: Correct sats_sup position and name. Re-base over new earlier patch.
--- a/xen/drivers/passthrough/amd/iommu_d
The common case is all IOMMUs having the same features. Log them only
for the first IOMMU, or for any that have a differing feature set.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_d
Despite the title this is actually all AMD IOMMU side work; all x86
side adjustments have already been carried out.
1: AMD/IOMMU: restrict feature logging
2: AMD/IOMMU: use bit field for extended feature register
3: AMD/IOMMU: use bit field for control register
4: AMD/IOMMU: use bit field for IRTE
Thanks for the patch! Looks like a good start; just a couple of comments:
On Wed, Jun 26, 2019 at 11:31 AM Nicolas Belouin
wrote:
>
> The Go bindings for libxl miss functions from libxl_utils, lets start
let's
> with the simple libxl_domid_to_name and its counterpart
> libxl_name_to_domid.
>
>
flight 138543 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138543/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-i386-prev 6 xen-bu
On Thu, Jun 27, 2019 at 05:25:06AM -0600, Jan Beulich wrote:
> >>> On 27.06.19 at 12:53, wrote:
> > On 27/06/2019 10:33, Roger Pau Monne wrote:
> >> --- a/xen/arch/arm/xen.lds.S
> >> +++ b/xen/arch/arm/xen.lds.S
> >> @@ -156,6 +156,7 @@ SECTIONS
> >> *(.init.rodata)
> >> *(.init.ro
On 27/06/2019 07:39, Jan Beulich wrote:
On 26.06.19 at 19:36, wrote:
>> Clang observes:
>>
>> tools/kconfig/conf.c:77:10:
>> warning: format string is not a string literal (potentially insecure)
>> [-Wformat-security]
>> printf(_("aborted!\n\n"));
>>
flight 138589 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138589/
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 27/06/2019 09:37, Roger Pau Monné wrote:
> On Wed, Jun 26, 2019 at 08:02:12PM +0100, Andrew Cooper wrote:
>> From: Sergey Dyasli
>>
>> Otherwise hvm_set_cr0() will check the wrong CR4 bits (L1 instead of L2
>> and vice-versa).
>>
>> Signed-off-by: Sergey Dyasli
>> Reviewed-by: Andrew Cooper
>
On Thu, Jun 27, 2019 at 12:51:05PM +0100, Andrew Cooper wrote:
> On 27/06/2019 10:33, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > index 8a8d8f060f..94e6c9aee3 100644
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -99,9 +99,14 @@
On 27/06/2019 13:10, Jan Beulich wrote:
On 27.06.19 at 13:51, wrote:
>> On 27/06/2019 10:33, Roger Pau Monne wrote:
>>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>>> index 8a8d8f060f..94e6c9aee3 100644
>>> --- a/xen/arch/x86/Makefile
>>> +++ b/xen/arch/x86/Makefile
>>> @@ -99
>>> On 27.06.19 at 13:51, wrote:
> On 27/06/2019 10:33, Roger Pau Monne wrote:
>> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
>> index 8a8d8f060f..94e6c9aee3 100644
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -99,9 +99,14 @@ endif
>> syms-warn-dup-y := --war
On 27/06/2019 10:33, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 8a8d8f060f..94e6c9aee3 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -99,9 +99,14 @@ endif
> syms-warn-dup-y := --warn-dup
> syms-warn-dup-$(CONFIG_SUPPRESS_D
flight 138588 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138588/
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 27/06/2019 12:07, Roger Pau Monné wrote:
> On Thu, Jun 27, 2019 at 11:59:46AM +0100, Andrew Cooper wrote:
>> On 27/06/2019 10:33, Roger Pau Monne wrote:
>>> if the hypervisor has been built with EFI support (ie: multiboot2).
>>> This allows to position the .reloc section correctly in the output
>>> On 27.06.19 at 11:33, wrote:
> After building the hypervisor binary. Note that the check is performed
> by searching for the magic header value at the start of the binary.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel m
>>> On 27.06.19 at 12:53, wrote:
> On 27/06/2019 10:33, Roger Pau Monne wrote:
>> --- a/xen/arch/arm/xen.lds.S
>> +++ b/xen/arch/arm/xen.lds.S
>> @@ -156,6 +156,7 @@ SECTIONS
>> *(.init.rodata)
>> *(.init.rodata.rel)
>> *(.init.rodata.str*)
>> + *(.init.rodata.cst*)
>
>>> On 27.06.19 at 11:33, wrote:
> if the hypervisor has been built with EFI support (ie: multiboot2).
> This allows to position the .reloc section correctly in the output
> binary.
>
> Note that for the ELF output format the .reloc section is moved before
> .bss because the data it contains is r
On Thu, Jun 27, 2019 at 11:59:46AM +0100, Andrew Cooper wrote:
> On 27/06/2019 10:33, Roger Pau Monne wrote:
> > if the hypervisor has been built with EFI support (ie: multiboot2).
> > This allows to position the .reloc section correctly in the output
> > binary.
> >
> > Note that for the ELF outpu
Hi Stefano,
On 26/06/2019 22:08, Stefano Stabellini wrote:
On Wed, 26 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 6/26/19 8:29 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
At the moment BSS is zeroed before the MMU and D-Cache is turned on.
In other words, the cach
On 27/06/2019 10:33, Roger Pau Monne wrote:
> if the hypervisor has been built with EFI support (ie: multiboot2).
> This allows to position the .reloc section correctly in the output
> binary.
>
> Note that for the ELF output format the .reloc section is moved before
> .bss because the data it cont
flight 138586 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138586/
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 27/06/2019 10:33, Roger Pau Monne wrote:
> Note that those sections when not prefixed with .init are already
> handled by the more general .rodata.* matching pattern in the .rodata
> output section.
>
> Signed-off-by: Roger Pau Monné
So, in hindsight, we'll never get .cst in .data, because of
flight 138498 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138498/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 138282
test-amd64-amd64-libvirt 13 migrat
if the hypervisor has been built with EFI support (ie: multiboot2).
This allows to position the .reloc section correctly in the output
binary.
Note that for the ELF output format the .reloc section is moved before
.bss because the data it contains is read-only, so it belongs with the
other section
Note that those sections when not prefixed with .init are already
handled by the more general .rodata.* matching pattern in the .rodata
output section.
Signed-off-by: Roger Pau Monné
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/arm/x
After building the hypervisor binary. Note that the check is performed
by searching for the magic header value at the start of the binary.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
Changes since v2:
- Use a variable to store the intermediate file nam
Hi Stefano,
On 26/06/2019 20:30, Julien Grall wrote:
On 6/26/19 8:01 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the
flight 138488 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138488/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
build-armhf-pvops
Hi Stefano,
On 26/06/2019 20:02, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime
flight 138583 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138583/
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 Wed, Jun 26, 2019 at 08:02:12PM +0100, Andrew Cooper wrote:
> From: Sergey Dyasli
>
> Otherwise hvm_set_cr0() will check the wrong CR4 bits (L1 instead of L2
> and vice-versa).
>
> Signed-off-by: Sergey Dyasli
> Reviewed-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> ---
> CC: Jan Beul
On Wed, Jun 26, 2019 at 03:37:26PM +0200, Juergen Gross wrote:
> After a reboot of a guest only the first pci device configuration will
> be retrieved from Xenstore resulting in loss of any further assigned
> passed through pci devices.
>
> The main reason is that all passed through pci devices re
Go is doing more type check (even when using CGo), so these incorrect
use of `unsafe.Pointer` as well as the lack of `unsafe.Pointer` for
these calls no longer compile with recent Go versions.
This does *not* break compatibility with older Go version.
---
tools/golang/xenlight/xenlight.go | 8 +++
flight 138582 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138582/
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-
72 matches
Mail list logo
