On 19.11.2019 18:58, Anthony PERARD wrote:
> Following the patch 65d104984c04 ("x86: fix race to build
> arch/x86/efi/relocs-dummy.o"), the error message
> nm: 'efi/relocs-dummy.o': No such file"
> started to appear on system which can't build the .efi target. This is
> because relocs-dummy.o
On 19.11.2019 18:00, Andrew Cooper wrote:
> c/s ff66ccefe5 "x86/CPUID: adjust SSEn dependencies" made SSE4A depend on
> SSSE3, but these processors really do have have SSE4A without SSSE3.
>
> This manifests as an upgrade regression, as the SSE4A feature disappears from
> view.
>
> Adjust the
On 20.11.2019 03:39, Boris Ostrovsky wrote:
> On 11/19/19 9:17 PM, Boris Ostrovsky wrote:
>> On 11/19/19 12:50 PM, Boris Ostrovsky wrote:
>>> On 11/19/19 7:58 AM, Jan Beulich wrote:
On 11.11.2019 15:30, Jan Beulich wrote:
> The first patch here fixes another regression from 3c88c692c287
On 19.11.2019 18:50, Boris Ostrovsky wrote:
> On 11/19/19 7:58 AM, Jan Beulich wrote:
>> On 11.11.2019 15:30, Jan Beulich wrote:
>>> The first patch here fixes another regression from 3c88c692c287
>>> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
>>> one already addressed by
>>>
flight 144209 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144209/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 144197
On 01.11.19 21:24, Andrew Cooper wrote:
I decided to dust off my early CPUID adjustments work in an effort to get
patch 3 in a sensible state for 4.13. Ever so slightly RFC for 4.13 given
where we are in the release, but this is fairly self contained.
Andrew Cooper (2):
x86/boot: Remove
flight 144207 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144207/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
On 11/19/19 9:17 PM, Boris Ostrovsky wrote:
> On 11/19/19 12:50 PM, Boris Ostrovsky wrote:
>> On 11/19/19 7:58 AM, Jan Beulich wrote:
>>> On 11.11.2019 15:30, Jan Beulich wrote:
The first patch here fixes another regression from 3c88c692c287
("x86/stackframe/32: Provide consistent
On Thu, Nov 14, 2019 at 01:06:41PM +, Pawel Wieczorkiewicz wrote:
> This series introduces new features to the livepatch functionality as
> briefly discussed during Xen Developer Summit 2019: [a] and [b].
> It also provides a few fixes and some small improvements.
>
> Main changes in v4:
> -
On 11/19/19 12:50 PM, Boris Ostrovsky wrote:
> On 11/19/19 7:58 AM, Jan Beulich wrote:
>> On 11.11.2019 15:30, Jan Beulich wrote:
>>> The first patch here fixes another regression from 3c88c692c287
>>> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
>>> one already addressed by
>>>
flight 144206 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144206/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
On 18.11.2019 17:25, George Dunlap wrote:
Where were these values collected -- on a PV dom0? Or from within the
guest?
Neither. Bare metal kernel - no Xen at all.
Could you try this with `0111` instead?
Works. '1000' crashes again. Now it is clear that 7 is the maximum
Windows accepts.
flight 144205 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144205/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144042
On Fri, Nov 15, 2019 at 10:33:24AM +, Oleksandr Andrushchenko wrote:
> On 11/15/19 11:21 AM, Daniel Vetter wrote:
> > The current code is a pretty good wtf moment, since we drop the
> > reference before we use it. It's not a big deal, because a) we only
> > use the pointer, so doesn't blow up
On 19/11/2019 15:23, Jan Beulich wrote:
> On 19.11.2019 15:58, Andrew Cooper wrote:
>> On 19/11/2019 11:13, Jan Beulich wrote:
>>> On 18.11.2019 19:15, Andrew Cooper wrote:
>>> I take it you imply that L0_ERROR would need raising (as per the
>>> auxiliary code fragment adding the "(access_x &&
flight 144210 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144210/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hi Andre,
On 12/11/2019 12:46, Andre Przywara wrote:
On Mon, 11 Nov 2019 11:01:07 -0800 (PST)
Stefano Stabellini wrote:
On Sat, 9 Nov 2019, Julien Grall wrote:
On Sat, 9 Nov 2019, 04:27 Stefano Stabellini, wrote:
On Thu, 7 Nov 2019, Peng Fan wrote:
> The end should be
I test v3 and it works fine.
Regards,
Philip
On 2019-11-12 3:22 p.m., Jason Gunthorpe wrote:
From: Jason Gunthorpe
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_interval notifier.
Although this driver does not seem to use the collision retry
On Tue, 19 Nov 2019 at 16:47, Ian Jackson wrote:
[...]
>
> > >From 1a8de36699b9042c30797e05f7a5f4313d7f7ad1 Mon Sep 17 00:00:00 2001
> > From: Ian Jackson
> > Date: Tue, 29 Oct 2019 17:45:30 +
> > Subject: [PATCH] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for
> > shim
> >
On 12/11/2019 11:38, Dietmar Hahn wrote:
> Hi,
>
> on a new machine with cpu Intel(R) Xeon(R) Gold 6242 CPU the kexec/kdump
> doesn't work with current xen-4.13.0-rc.
> The last output of the xen console is:
>
> (XEN) Hardware Dom0 crashed: Executing kexec image on cpu5
> (XEN) Shot down all
On Mon, Nov 18, 2019 at 2:53 AM Jan Beulich wrote:
>
> On 18.11.2019 09:38, Alexandru Stefan ISAILA wrote:
> > On 12.11.2019 14:02, Jan Beulich wrote:
> >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> >>> @@ -2572,17 +2574,36 @@ int p2m_init_altp2m_by_id(struct domain *d,
> >>> unsigned
> On 18. Nov 2019, at 18:41, Sergey Dyasli wrote:
>
> On 18/11/2019 17:28, Wieczorkiewicz, Pawel wrote:
>>
>> Could you build the lp with debug (-d) and provide me with the
>> create-diff-object.log file?
>>
>
> I've attached the log. Btw, I think I provided all the necessary information
>
Following the patch 65d104984c04 ("x86: fix race to build
arch/x86/efi/relocs-dummy.o"), the error message
nm: 'efi/relocs-dummy.o': No such file"
started to appear on system which can't build the .efi target. This is
because relocs-dummy.o isn't built anymore.
The error is printed by the
On 11/19/19 7:58 AM, Jan Beulich wrote:
> On 11.11.2019 15:30, Jan Beulich wrote:
>> The first patch here fixes another regression from 3c88c692c287
>> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
>> one already addressed by
>>
On Tue, Nov 12, 2019 at 11:57:32AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure:
> Honour XEN_COMPILE_ARCH and _TARGET_ for shim"):
> > Andrew Cooper writes ("Re: [Xen-devel] [XEN PATCH for-4.13]
> > tools/configure: Honour
On 11/14/19 1:06 PM, Pawel Wieczorkiewicz wrote:
> Extend the XC python bindings library to support also all common
> livepatch operations and actions.
>
> Add the python bindings for the following operations:
> - status (pyxc_livepatch_status):
> Requires a payload name as an input.
>
On 11/14/19 1:06 PM, Pawel Wieczorkiewicz wrote:
> Extend the livepatch list operation to fetch also payloads' metadata.
> This is achieved by extending the sysctl list interface with 2 extra
> guest handles:
> * metadata - an array of arbitrary size strings
> * metadata_len - an array of
On 19.11.19 18:00, Andrew Cooper wrote:
c/s ff66ccefe5 "x86/CPUID: adjust SSEn dependencies" made SSE4A depend on
SSSE3, but these processors really do have have SSE4A without SSSE3.
This manifests as an upgrade regression, as the SSE4A feature disappears from
view.
Adjust the SSE4A feature to
c/s ff66ccefe5 "x86/CPUID: adjust SSEn dependencies" made SSE4A depend on
SSSE3, but these processors really do have have SSE4A without SSSE3.
This manifests as an upgrade regression, as the SSE4A feature disappears from
view.
Adjust the SSE4A feature to depend on SSE3 rather than SSSE3.
On Tue, Nov 19, 2019 at 05:32:53PM +0100, Jan Beulich wrote:
> On 19.11.2019 17:27, Jan Beulich wrote:
> > On 14.11.2019 19:05, Anthony PERARD wrote:
> >> With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile
> >> will attempt to build that object. This result in the dependency
On 17.11.19 00:47, Marek Marczykowski-Górecki wrote:
Before df6631 "efi: use directmap to access runtime services table"
all usages of efi_rs pointer were guarded by efi_rs_enter(), which
implicitly refused to operate with efi=no-rs (by checking if
efi_l4_pgtable is NULL - which is the case
Ian Jackson writes ("Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure:
Honour XEN_COMPILE_ARCH and _TARGET_ for shim"):
> Andrew, did you want to ack this ? Or do you have further comments ?
> I have a release-ack...
Hrm. get_maintainer thinks this is for Wei. CC'd.
Ian.
> >From
Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 4/4] libxl:
gentypes: initialise array elements in json"):
> On Tue, Oct 29, 2019 at 03:54:36PM +, Ian Jackson wrote:
> > +lambda(by): ("&" if by == idl.PASS_BY_REFERENCE else
> > "")+
>
> The syntax for
On 11/14/19 1:06 PM, Pawel Wieczorkiewicz wrote:
> The payloads' name strings can be of arbitrary size (typically small
> with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
> Current implementation of the list operation interface allows to copy
> names in the XEN_LIVEPATCH_NAME_SIZE chunks
On 19.11.2019 16:15, Andrew Cooper wrote:
> On 13/11/2019 13:29, Jan Beulich wrote:
>> On 13.11.2019 14:22, Andrew Cooper wrote:
>>> I am not convinced the behaviour is worth changing, and I don't have
>>> time for this scope creep.
>> There's no scope creep here at all.
>
> Yes - it really is
On 19.11.2019 17:27, Jan Beulich wrote:
> On 14.11.2019 19:05, Anthony PERARD wrote:
>> With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile
>> will attempt to build that object. This result in the dependency file
>> been generated with relocs-dummy.o depending on
On 14.11.2019 19:05, Anthony PERARD wrote:
> With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile
> will attempt to build that object. This result in the dependency file
> been generated with relocs-dummy.o depending on efi/relocs-dummy.o.
>
> Then, when arch/x86/efi/Makefile
Hi Artem,
On 19/11/2019 15:16, Artem Mygaiev wrote:
Unfortunately this is not the case - we need to specify 2 different
targets: 1st is for GNU tools which are still used when building with
armclang, for debug symbols dumping etc. (there is no replacement in
Arm toolstack for them, and this is
On 19.11.2019 15:58, Andrew Cooper wrote:
> On 19/11/2019 11:13, Jan Beulich wrote:
>> On 18.11.2019 19:15, Andrew Cooper wrote:
>> I take it you imply that L0_ERROR would need raising (as per the
>> auxiliary code fragment adding the "(access_x && *page_order)"
>> check), but I wonder whether
Hi Julien
On Mon, 2019-11-18 at 06:18 +, Julien Grall wrote:
>
> On 14/11/2019 14:12, Artem Mygaiev wrote:
> > Hello Julien
>
> Hi,
>
> > On Thu, 2019-11-14 at 08:19 +0900, Julien Grall wrote:
> > >
> > > On Thu, 14 Nov 2019, 02:15 Artem Mygaiev, <
> > > artem_myga...@epam.com
> > > >
On 13/11/2019 13:29, Jan Beulich wrote:
> On 13.11.2019 14:22, Andrew Cooper wrote:
>> I am not convinced the behaviour is worth changing, and I don't have
>> time for this scope creep.
> There's no scope creep here at all.
Yes - it really is scope creep.
This patch does not change the behaviour
flight 144202 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144202/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 144197
Tests which did
On 19/11/2019 11:13, Jan Beulich wrote:
> On 18.11.2019 19:15, Andrew Cooper wrote:
>> When nestedhvm_hap_nested_page_fault() returns L0_ERROR,
>> hvm_hap_nested_page_fault() operates on the adjusted gpa. However, it
>> operates with the original npfec, which is no longer be correct.
> Nit:
Adding,
Artem as this is potentially of interest to the FuSa group?
Lars
> On 14 Nov 2019, at 13:33, Jeff Kubascik wrote:
>
> Hello,
>
> I'm working on a port of a RTOS (RTEMS) to Xen on ARM, and came across an
> interesting finding in how Xen emulates the physical timer on ARM.
>
> In
On 19.11.2019 15:31, Andreas Kinzler wrote:
> On 19.11.2019 10:29, Jan Beulich wrote:
>> Now would you be up to checking whether, rather than via BIOS
>> settings (which not all BIOSes may offer) the same can be
>> achieved by using Xen's command line option "max_cstate="?
>> Also did you check
flight 144204 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144204/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 144165
On 19.11.2019 10:29, Jan Beulich wrote:
On 18.11.2019 20:35, Andreas Kinzler wrote:
On 15.11.2019 12:01, Andreas Kinzler wrote:
On 14.11.2019 12:29, Jan Beulich wrote:
On 14.11.2019 00:10, Andreas Kinzler wrote:
I came across the following: https://lkml.org/lkml/2019/8/29/536
Could that be
On Mon, Nov 18, 2019 at 11:15:43PM -0800, Roman Shaposhnik wrote:
> On Sun, Nov 17, 2019 at 5:27 PM Marek Marczykowski-Górecki
> wrote:
> >
> > On Sun, Nov 17, 2019 at 05:06:11PM -0800, Roman Shaposhnik wrote:
> > > Rich, Marek, thanks a million for quick replies -- I'll try your
> > >
On 11.11.19 15:32, Jan Beulich wrote:
This can be had with two instead of six insns, by just checking the high
CS.RPL bit.
Also adjust the comment - there would be no #GP in the mentioned cases,
as there's no segment limit violation or alike. Instead there'd be #PF,
but that one reports the
On 11.11.19 15:32, Jan Beulich wrote:
Now that SS:ESP always get saved by SAVE_ALL, this also needs to be
accounted for in xen_iret_crit_fixup. Otherwise the old_ax value gets
interpreted as EFLAGS, and hence VM86 mode appears to be active all
the time, leading to random "vm86_32: no user_vm86:
On 11.11.2019 15:30, Jan Beulich wrote:
> The first patch here fixes another regression from 3c88c692c287
> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
> one already addressed by
> https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
> The second patch is
On 19.11.2019 13:08, Anthony PERARD wrote:
> This hypercall can take a long time to finish because it attempts to
> grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
> lock can take several seconds.
Which means several milliseconds on average per lock acquire. This
points
Hi,
On 17/11/2019 22:32, Stewart Hildebrand wrote:
CC'ing Julien's new email address
For Xen-devel, I have filter to get in my inbox all e-mails where my
@arm.com is CCed :).
On Thursday, November 14, 2019 2:33 PM, Jeff Kubascik wrote:
Hello,
I'm working on a port of a RTOS (RTEMS) to
On Mon, Nov 18, 2019 at 7:55 PM Ian Jackson wrote:
>
> Oleksandr Grytsov writes ("[PATCH v1 1/2] libxl: introduce new backend type
> VINPUT"):
> > From: Oleksandr Grytsov
> >
> > There are two kind of VKBD devices: with QEMU backend and user space
> > backend. In current implementation they
flight 144201 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144201/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
This hypercall can take a long time to finish because it attempts to
grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
lock can take several seconds.
This can easily happen with a guest with 32 vcpus and plenty of RAM,
during localhost migration.
Signed-off-by: Anthony
On 18.11.2019 19:15, Andrew Cooper wrote:
> When nestedhvm_hap_nested_page_fault() returns L0_ERROR,
> hvm_hap_nested_page_fault() operates on the adjusted gpa. However, it
> operates with the original npfec, which is no longer be correct.
Nit: Perhaps "may" instead of "is"?
> In particular, it
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 189eb7f3d7ec70ceeaa195221ddfd95016e10ace
Gitweb:
https://git.kernel.org/tip/189eb7f3d7ec70ceeaa195221ddfd95016e10ace
Author:Jan Beulich
AuthorDate:Mon, 18 Nov 2019 16:21:12 +01:00
flight 144200 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
On 18.11.2019 20:35, Andreas Kinzler wrote:
> On 15.11.2019 12:01, Andreas Kinzler wrote:
>> On 14.11.2019 12:29, Jan Beulich wrote:
>>> On 14.11.2019 00:10, Andreas Kinzler wrote:
I came across the following: https://lkml.org/lkml/2019/8/29/536
Could that be the reason for the problem
On 19.11.2019 10:05, Alexandru Stefan ISAILA wrote:
> On 18.11.2019 16:09, Jan Beulich wrote:
>> On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote:
>>> For this HVMOP_ALTP2M_INTERFACE_VERSION shout be increased. I will leave
>>> it to Tamas to decide if we will need a different structure for
>>>
On 19.11.2019 06:23, Rishi wrote:
> ok, thanks for clearing it up. Would a patch be accepted if this
> option of showing EAX leaf is selectively done through command line
> (default disabled)?
In general I'd expect this to be rather unlikely, but I guess much
would depend on the actual reasoning
* Jan Beulich wrote:
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot. Adjust BUG_IF_WRONG_CR3
> as well to guard against future uses of the macro on a code
63 matches
Mail list logo
