flight 155828 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155828/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 155815 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155815/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-pvhv2-intel 12 debian-install fail in 155799 pass in 155815
test-amd64-amd64-pygrub 13 gu
flight 155810 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155810/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 155788
build-amd64-xsm
On 14.10.20 18:27, Jason Andryuk wrote:
On Wed, Oct 14, 2020 at 12:12 PM Jürgen Groß wrote:
On 14.10.20 17:31, Jason Andryuk wrote:
Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
This wrong. Have a look into arch/x86/platform/pvh/head.S
That is XEN_ELFNOTE_PHYS32_E
On Thu, Oct 15, 2020 at 03:02:59AM +0200, Marek Marczykowski-G??recki wrote:
> On Tue, Oct 13, 2020 at 01:26:06PM +, Wei Liu wrote:
> > On Sun, Oct 11, 2020 at 06:11:39PM -0700, Elliott Mitchell wrote:
> > > Having looked around a bit, I believe this is a Python 2/3 compatibility
> > > issue.
flight 155809 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155809/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
flight 155822 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155822/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 155805
Tests which
On Tue, Oct 13, 2020 at 01:26:06PM +, Wei Liu wrote:
> On Sun, Oct 11, 2020 at 06:11:39PM -0700, Elliott Mitchell wrote:
> > Unexpectedly the environment variable which needs to be passed is
> > $LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
> > of the host `ld`.
> >
On Sun, Oct 11, 2020 at 06:11:39PM -0700, Elliott Mitchell wrote:
> Unexpectedly the environment variable which needs to be passed is
> $LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
> of the host `ld`.
>
> Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared o
Hi,
The v5 series of the device-dax-subdivision series landed upstream which
missed some of the late breaking fixups in v6 [1]. The Xen one is
cosmetic, the kmem one is a functional problem. I will handle the kmem
in a device-dax follow-on pull request post-rc1. The Xen one can go
through the Xen
Cleanup fill_list() to keep all the pgmap manipulations in a single
location of the function. Update the exit unwind path accordingly.
Link: http://lore.kernel.org/r/6186fa28-d123-12db-6171-a75cb6e61...@oracle.com
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Andrew Morton
Cc:
Reported-by: Bor
Hi All,
I'm currently using Xen 4.14 (Qubes 4.1 OS) on a Ryzen 7 4750U PRO, by default
I'll experience softlocks where the mouse for example will jolt from time to
time, in this state it's not usable.
Adding `dom0_max_vcpus=1 dom0_vcpus_pin` to Xen's CMDLINE results in no more
jolting however
flight 155818 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155818/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 155805
Tests which
flight 155802 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155802/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
test-amd64-amd64-
On Wed, 14 Oct 2020, Julien Grall wrote:
> On 14/10/2020 17:03, Bertrand Marquis wrote:
> > > On 14 Oct 2020, at 12:35, Andrew Cooper wrote:
> > >
> > > On 14/10/2020 11:41, Bertrand Marquis wrote:
> > > > When a Cortex A57 processor is affected by CPU errata 832075, a guest
> > > > not implement
On Wed, 14 Oct 2020, Bertrand Marquis wrote:
> > On 14 Oct 2020, at 12:11, Julien Grall wrote:
> >
> > Hi Bertrand,
> >
> > On 14/10/2020 11:41, Bertrand Marquis wrote:
> >> When a Cortex A57 processor is affected by CPU errata 832075, a guest
> >> not implementing the workaround for it could de
flight 155811 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155811/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 155805
Tests which
flight 155801 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155801/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5d0a827122cccd1f884faf75b2a065d88a58bce1
baseline version:
ovmf 9380177354387f03c8ff9
On Wed, 14 Oct 2020, Jan Beulich wrote:
> When processing "chain" directives, the previously loaded config file
> gets freed. This needs to be recorded accordingly such that no error
> path would try to free the same block of memory a 2nd time.
>
> Furthermore, neither .addr nor .size being zero h
flight 155799 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 12 debian-installfail REGR. vs. 155534
test-amd64-amd64-pygr
On 14/10/2020 20:28, Jason Andryuk wrote:
> Hi,
>
> Bug opened at https://gitlab.freedesktop.org/drm/intel/-/issues/2576
>
> I'm seeing DMA faults for the i915 graphics hardware on a Dell
> Latitude 5500. These were captured when I plugged into a Dell
> Thunderbolt dock with two DisplayPort monitor
On Wed, Oct 14, 2020 at 2:04 PM Andrew Cooper wrote:
>
> On 14/10/2020 18:53, Jason Andryuk wrote:
> > A Xen PVH domain doesn't have a PCI bus or devices,
>
> [*] Yet.
:)
> > so it doesn't need PCI support built in.
>
> Untangling the dependences is a good thing, but eventually we plan to
> put
Hi,
Bug opened at https://gitlab.freedesktop.org/drm/intel/-/issues/2576
I'm seeing DMA faults for the i915 graphics hardware on a Dell
Latitude 5500. These were captured when I plugged into a Dell
Thunderbolt dock with two DisplayPort monitors attached. Xen 4.12.4
staging and Linux 5.4.70 (and
cpu_smpboot_alloc() is designed to be idempotent with respect to partially
initialised state. This occurs for S3 and CPU parking, where enough state to
handle NMIs/#MCs needs to remain valid for the entire lifetime of Xen, even
when we otherwise want to offline the CPU.
For simplicity between var
On 14/10/2020 18:53, Jason Andryuk wrote:
> A Xen PVH domain doesn't have a PCI bus or devices,
[*] Yet.
> so it doesn't need PCI support built in.
Untangling the dependences is a good thing, but eventually we plan to
put an optional PCI bus back in, e.g. for SRIOV usecases.
~Andrew
On 13/10/2020 16:51, Jan Beulich wrote:
> On 12.10.2020 15:49, Andrew Cooper wrote:
>> All interrupts and exceptions pass a struct cpu_user_regs up into C. This
>> contains the legacy vm86 fields from 32bit days, which are beyond the
>> hardware-pushed frame.
>>
>> Accessing these fields is genera
Moving XEN_512GB allows it to nest under XEN_PV. That also allows
XEN_PVH to nest under XEN as a sibling to XEN_PV and XEN_PVHVM giving:
[*] Xen guest support
[*] Xen PV guest support
[*] Limit Xen pv-domain memory to 512GB
[*] Xen PV Dom0 support
[*] Xen PVHVM guest support
A Xen PVH domain doesn't have a PCI bus or devices, so it doesn't need
PCI support built in. Currently, XEN_PVH depends on XEN_PVHVM which
depends on PCI.
Introduce XEN_PVHVM_GUEST as a toplevel item and change XEN_PVHVM to a
hidden variable. This allows XEN_PVH to depend on XEN_PVHVM without PC
A Xen PVH domain doesn't have a PCI bus or devices, so it doesn't need
PCI support built in. Currently, XEN_PVH depends on XEN_PVHVM which
depends on PCI.
The first patch introduces XEN_PVHVM_GUEST as a toplevel item and
changes XEN_PVHVM to a hidden variable. This allows XEN_PVH to depend
on XE
Hi Elliot,
On 14/10/2020 02:37, Elliott Mitchell wrote:
On Tue, Oct 13, 2020 at 06:06:26PM -0700, Stefano Stabellini wrote:
On Mon, 12 Oct 2020, Elliott Mitchell wrote:
I'm on different hardware, but some folks have setup Tianocore for it.
According to Documentation/arm64/acpi_object_usage.rst
Hi,
On 12/10/2020 20:02, Stefano Stabellini wrote:
On Sat, 10 Oct 2020, Julien Grall wrote:
On 28/09/2020 07:47, Masami Hiramatsu wrote:
Hello,
Hi Masami,
This made progress with my Xen boot on DeveloperBox (
https://www.96boards.org/product/developerbox/ ) with ACPI.
I have reviewed th
On 14/10/2020 17:28, Roger Pau Monné wrote:
> On Fri, Oct 09, 2020 at 12:53:01PM +0100, Andrew Cooper wrote:
>> Despite appearing to be a deliberate design choice of early PV64, the
>> resulting behaviour for unregistered SYSCALL callbacks creates an untenable
>> testability problem for Xen. Furth
The pull request you sent on Wed, 14 Oct 2020 07:39:17 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.10b-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a09b1d78505eb9fe27597a5174c61a7c66253fe8
Thank you!
--
Deet-doot-dot,
Hi Bertrand,
On 14/10/2020 17:03, Bertrand Marquis wrote:
On 14 Oct 2020, at 12:35, Andrew Cooper wrote:
On 14/10/2020 11:41, Bertrand Marquis wrote:
When a Cortex A57 processor is affected by CPU errata 832075, a guest
not implementing the workaround for it could deadlock the system.
Add
Hi Andrew,
On 14/10/2020 12:35, Andrew Cooper wrote:
On 14/10/2020 11:41, Bertrand Marquis wrote:
When a Cortex A57 processor is affected by CPU errata 832075, a guest
not implementing the workaround for it could deadlock the system.
Add a warning during boot informing the user that only truste
On 14/10/2020 12:06, Michal Orzel wrote:
Hi Julien,
I agree. You can update the commit message.
Thanks. I have updated the commit message and committed it.
On a different topic, it looks like you are sending the e-mail with
HTML. Would you mind to configure it to send plain text?
Cheers
On 14/10/2020 16:47, Jan Beulich wrote:
> On 13.10.2020 05:02, Igor Druzhinin wrote:
>> LBR, C-state MSRs and if_pschange_mc erratum applicability should correspond
>> to Ice Lake desktop according to External Design Specification vol.2.
>
> Could you tell me where this is publicly available? Even
On Fri, Oct 09, 2020 at 12:53:01PM +0100, Andrew Cooper wrote:
> Despite appearing to be a deliberate design choice of early PV64, the
> resulting behaviour for unregistered SYSCALL callbacks creates an untenable
> testability problem for Xen. Furthermore, the behaviour is undocumented,
> bizarre,
On Wed, Oct 14, 2020 at 12:12 PM Jürgen Groß wrote:
>
> On 14.10.20 17:31, Jason Andryuk wrote:
> > Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
>
> This wrong. Have a look into arch/x86/platform/pvh/head.S
That is XEN_ELFNOTE_PHYS32_ENTRY, which is different from
XEN_EL
On Wed, Oct 14, 2020 at 12:02 PM Jan Beulich wrote:
>
> On 14.10.2020 17:31, Jason Andryuk wrote:
> > Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
> > kernel build CONFIG_PVH=y CONFIG_PV=n lacks the note. In this case,
> > virt_entry will be UNSET_ADDR, overwritten by th
Add a check for snprintf return code and ignore the entry if we get an
error. This should in fact never happen and is more a trick to make gcc
happy and prevent compilation errors.
This is solving the following gcc warning when compiling for arm32 host
platforms with optimization activated:
xenpmd
On 14.10.20 17:31, Jason Andryuk wrote:
Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
This wrong. Have a look into arch/x86/platform/pvh/head.S
Juergen
On 13.10.2020 05:02, Igor Druzhinin wrote:
> From: Chen Yu
>
> On ICX platform, the C1E auto-promotion is enabled by default.
> As a result, the CPU might fall into C1E more offen than previous
> platforms. So disable C1E auto-promotion and expose C1E as a separate
> idle state.
>
> Beside C1 an
> On 14 Oct 2020, at 12:35, Andrew Cooper wrote:
>
> On 14/10/2020 11:41, Bertrand Marquis wrote:
>> When a Cortex A57 processor is affected by CPU errata 832075, a guest
>> not implementing the workaround for it could deadlock the system.
>> Add a warning during boot informing the user that o
On 14.10.2020 17:31, Jason Andryuk wrote:
> Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
> kernel build CONFIG_PVH=y CONFIG_PV=n lacks the note. In this case,
> virt_entry will be UNSET_ADDR, overwritten by the ELF header e_entry,
> and fail the check against the virt add
> On 14 Oct 2020, at 12:11, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 14/10/2020 11:41, Bertrand Marquis wrote:
>> When a Cortex A57 processor is affected by CPU errata 832075, a guest
>> not implementing the workaround for it could deadlock the system.
>> Add a warning during boot informing
> On 14 Oct 2020, at 16:47, Wei Liu wrote:
>
> On Wed, Oct 14, 2020 at 10:58:33AM +, Bertrand Marquis wrote:
>> Hi,
>>
>> Could this be reviewed so that gcc10 issues are fixed ?
>
> I think Juergen's comments have been addressed.
>
> Acked-by: Wei Liu
Thanks :-)
On Wed, Oct 14, 2020 at 11:31:50AM -0400, Jason Andryuk wrote:
> Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
> kernel build CONFIG_PVH=y CONFIG_PV=n lacks the note. In this case,
> virt_entry will be UNSET_ADDR, overwritten by the ELF header e_entry,
> and fail the check
On Wed, Oct 14, 2020 at 10:58:33AM +, Bertrand Marquis wrote:
> Hi,
>
> Could this be reviewed so that gcc10 issues are fixed ?
I think Juergen's comments have been addressed.
Acked-by: Wei Liu
On 13.10.2020 05:02, Igor Druzhinin wrote:
> LBR, C-state MSRs and if_pschange_mc erratum applicability should correspond
> to Ice Lake desktop according to External Design Specification vol.2.
Could you tell me where this is publicly available? Even after spending
quite a bit of time on searching
On Wed, Oct 14, 2020 at 05:23:23PM +0200, Jan Beulich wrote:
> Relying on presence / absence of hypervisor leaves in raw / escaped
> CPUID output cannot be used to tell apart PV and HVM on CPUID faulting
> capable hardware. Utilize a PV-only feature flag to avoid false positive
> HVM detection.
>
On Wed, Oct 14, 2020 at 11:44:22AM +0200, Olaf Hering wrote:
> xc_map_foreign_bulk is an obsolete API, which is only used by
> qemu-xen-traditional.
>
> Adjust the error string to refer to the current API.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
flight 155805 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155805/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
kernel build CONFIG_PVH=y CONFIG_PV=n lacks the note. In this case,
virt_entry will be UNSET_ADDR, overwritten by the ELF header e_entry,
and fail the check against the virt address range.
Change the code to only check virt_en
Relying on presence / absence of hypervisor leaves in raw / escaped
CPUID output cannot be used to tell apart PV and HVM on CPUID faulting
capable hardware. Utilize a PV-only feature flag to avoid false positive
HVM detection.
While at it also short circuit the main detection loop: For PV, only
th
On 14/10/2020 15:16, Roger Pau Monné wrote:
>> This change does constitute a change in the PV ABI, for corner cases of a PV
>> guest kernel registering neither callback, or not registering the 32bit
>> callback when running on AMD/Hygon hardware.
> Is there any place suitable to document this behav
On 14/10/2020 15:20, Manuel Bouyer wrote:
> On Wed, Oct 14, 2020 at 04:16:20PM +0200, Roger Pau Monné wrote:
>> [...]
>> Would this result in a regression for NetBSD then? Is it fine to see
>> #UD regardless of the platform? It's not clear to me from the text
>> above whether this change will cause
On Wed, Oct 14, 2020 at 04:16:20PM +0200, Roger Pau Monné wrote:
> [...]
> Would this result in a regression for NetBSD then? Is it fine to see
> #UD regardless of the platform? It's not clear to me from the text
> above whether this change will cause issues with NetBSD.
AFAIK this should not caus
On Fri, Oct 09, 2020 at 12:53:01PM +0100, Andrew Cooper wrote:
> Despite appearing to be a deliberate design choice of early PV64, the
> resulting behaviour for unregistered SYSCALL callbacks creates an untenable
> testability problem for Xen. Furthermore, the behaviour is undocumented,
> bizarre,
On 13/10/2020 16:58, Jan Beulich wrote:
> On 09.10.2020 17:09, Andrew Cooper wrote:
>> At the time of XSA-170, the x86 instruction emulator really was broken, and
>> would allow arbitrary non-canonical values to be loaded into %rip. This was
>> fixed after the embargo by c/s 81d3a0b26c1 "x86emul:
flight 155791 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155791/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
On 23.09.20 08:45, Juergen Gross wrote:
Add support for creating a PVH Xenstore stub-domain.
This includes building the stubdom and loading it at system boot.
It should be noted that currently this stubdom is not in a working
state as there is some support in Mini-OS missing. I'm working on
add
Ping?
On 02.10.20 16:22, Juergen Gross wrote:
The rework of the Xen library build introduced creating some additional
symbolic links during the build process.
This series is undoing that by moving all official Xen library headers
to tools/include and by using include paths and the vpath directi
Ping?
On 09.09.20 13:59, Juergen Gross wrote:
Fix some paths after reorg of library locations, and drop unreachable
maintainer.
Juergen Gross (2):
maintainers: fix libxl paths
maintainers: remove unreachable remus maintainer
MAINTAINERS | 10 +-
1 file changed, 5 insertions(+)
flight 155800 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155800/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On 07.10.2020 12:20, Roger Pau Monne wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -253,6 +253,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
> *val)
> break;
> goto gp_fault;
>
> +case MSR_IA32_THERM_STATUS:
> +if ( cp->x86_ven
Hi Julien,
> On 14 Oct 2020, at 12:04, Julien Grall wrote:
>
> Hi,
>
> On 14/10/2020 11:47, Bertrand Marquis wrote:
>> Add a check for snprintf return code and ignore the entry if we get an
>> error. This should in fact never happen and is more a trick to make gcc
>> happy and prevent compilati
Hi Jan,
On 13/10/2020 15:26, Jan Beulich wrote:
On 13.10.2020 16:20, Jürgen Groß wrote:
On 13.10.20 15:58, Jan Beulich wrote:
On 12.10.2020 11:27, Juergen Gross wrote:
The queue for a fifo event is depending on the vcpu_id and the
priority of the event. When sending an event it might happen t
flight 155788 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155788/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pair 26 guest-migrate/src_host/dst_host fail in 155759 pass
in 155788
test-amd64-i386-xl-qemu
On 14/10/2020 11:41, Bertrand Marquis wrote:
> When a Cortex A57 processor is affected by CPU errata 832075, a guest
> not implementing the workaround for it could deadlock the system.
> Add a warning during boot informing the user that only trusted guests
> should be executed on the system.
> An e
flight 155793 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Hi Bertrand,
On 14/10/2020 11:41, Bertrand Marquis wrote:
When a Cortex A57 processor is affected by CPU errata 832075, a guest
not implementing the workaround for it could deadlock the system.
Add a warning during boot informing the user that only trusted guests
should be executed on the system
Hi Julien,
I agree. You can update the commit message.
Thanks for review.
Michal
From: Julien Grall
Sent: Wednesday, October 14, 2020 12:56 PM
To: Michal Orzel ; xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ; Volodymyr Babchuk
; Bertrand Marquis
Sub
Hi,
On 14/10/2020 11:47, Bertrand Marquis wrote:
Add a check for snprintf return code and ignore the entry if we get an
error. This should in fact never happen and is more a trick to make gcc
happy and prevent compilation errors.
This is solving the gcc warning:
xenpmd.c:92:37: error: '%s' dire
Hi,
> On 14 Oct 2020, at 11:05, Michal Orzel wrote:
>
> Workaround for Cortex-A57 erratum #852523 is already
> in Xen but Cortex-A72 erratum #853709 is not although
> it applies to the same issue.
>
> Signed-off-by: Michal Orzel
Reviewed-by: Bertrand Marquis
Change in commit message suggest
Hi,
Could this be reviewed so that gcc10 issues are fixed ?
Thanks
Bertrand
> On 7 Oct 2020, at 14:57, Bertrand Marquis wrote:
>
> Use memcpy in getBridge to prevent gcc warnings about truncated
> strings. We know that we might truncate it, so the gcc warning
> here is wrong.
> Revert previous
On 14/10/2020 11:42, Jan Beulich wrote:
> read_section() needs to be more careful: efi_arch_use_config_file()
> may have found a DTB file (but without modules), and there may be no DTB
> specified in the EFI config file. In this case the pointer to the blob
> must not be overwritten with NULL when
Hi Michal,
On 14/10/2020 11:05, Michal Orzel wrote:
Workaround for Cortex-A57 erratum #852523 is already
in Xen but Cortex-A72 erratum #853709 is not although
it applies to the same issue.
This commit message is a bit confusing because it implies that Xen
doesn't workaround #852523. However,
Add a check for snprintf return code and ignore the entry if we get an
error. This should in fact never happen and is more a trick to make gcc
happy and prevent compilation errors.
This is solving the gcc warning:
xenpmd.c:92:37: error: '%s' directive output may be truncated writing
between 4 and
When processing "chain" directives, the previously loaded config file
gets freed. This needs to be recorded accordingly such that no error
path would try to free the same block of memory a 2nd time.
Furthermore, neither .addr nor .size being zero has any meaning towards
the need to free an allocat
read_section() needs to be more careful: efi_arch_use_config_file()
may have found a DTB file (but without modules), and there may be no DTB
specified in the EFI config file. In this case the pointer to the blob
must not be overwritten with NULL when no ".dtb" section is present
either.
Fixes: 8a7
When a Cortex A57 processor is affected by CPU errata 832075, a guest
not implementing the workaround for it could deadlock the system.
Add a warning during boot informing the user that only trusted guests
should be executed on the system.
An equivalent warning is already given to the user by KVM o
The first change is, I believe, addressing the regression spotted by
osstest. The second change is simply a result of me going over the
involved code in, effectively, a re-review of the original changes.
1: EFI/Arm64: don't clobber DTB pointer
2: EFI: further "need_to_free" adjustments
Jan
Workaround for Cortex-A57 erratum #852523 is already
in Xen but Cortex-A72 erratum #853709 is not although
it applies to the same issue.
Signed-off-by: Michal Orzel
---
docs/misc/arm/silicon-errata.txt | 1 +
xen/arch/arm/domain.c| 6 --
2 files changed, 5 insertions(+), 2 deleti
xc_map_foreign_bulk is an obsolete API, which is only used by
qemu-xen-traditional.
Adjust the error string to refer to the current API.
Signed-off-by: Olaf Hering
---
tools/libs/foreignmemory/freebsd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libs/foreignme
flight 155785 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
test-amd64-amd64-
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tr
flight 155796 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On 14.10.20 08:52, Jan Beulich wrote:
On 14.10.2020 08:00, Jürgen Groß wrote:
On 13.10.20 17:28, Jan Beulich wrote:
On 12.10.2020 11:27, Juergen Gross wrote:
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -105,6 +105,45 @@ void notify_via_xen_event_channel(struct domain *ld, in
On 14/10/2020 08:05, Jan Beulich wrote:
> In the context of working on x86's elf_core_save_regs() I noticed there
> were far more source files getting rebuilt than I would have expected.
> While the main offender looks to have been fixmap.h including kexec.h,
> also drop use of elfcore.h from kexec
On 14/10/2020 08:04, Jan Beulich wrote:
> It has no users and hasn't been touched in 10 years.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
In the context of working on x86's elf_core_save_regs() I noticed there
were far more source files getting rebuilt than I would have expected.
While the main offender looks to have been fixmap.h including kexec.h,
also drop use of elfcore.h from kexec.h.
While adjusting machine_kexec.c also replac
It has no users and hasn't been touched in 10 years.
Signed-off-by: Jan Beulich
--- a/xen/include/xen/hash.h
+++ /dev/null
@@ -1,58 +0,0 @@
-#ifndef _XEN_HASH_H
-#define _XEN_HASH_H
-/* Fast hashing routine for a long.
- (C) 2002 William Lee Irwin III, IBM */
-
-/*
- * Knuth recommends primes
93 matches
Mail list logo
