Re: [edk2-devel] [PATCH v2 15/31] OvmfPkg/XenHypercallLib: Enable it in PEIM

On 04/09/19 13:08, Anthony PERARD wrote: > Allow to use Xen hypercalls earlier, during the PEIM stage, but > XenHypercallLibReInit() must be called once the XenInfo HOB is created > with the HyperPage setup. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Anthony

Re: [edk2-devel] [PATCH v2 20/31] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h

On 04/09/19 13:08, Anthony PERARD wrote: > This is copied over from the public header of the Xen Project, with the (1) Please expand "This". with that, Acked-by: Laszlo Ersek Thanks Laszlo > type name modified to build on OVMF. > > Contributed-under: TianoCore Contribution Agreement 1.1 >

Re: [Xen-devel] [PATCH v1] libxl: fix migration of PV and PVH domUs with and without qemu

Am Thu, 11 Apr 2019 16:56:02 +0100 schrieb Anthony PERARD : > I haven't managed to reproduce this, but this bug will go away with > QEMU 4.0. The backend in QEMU 4.0 will not lock the disk image anymore. I also have a hard time to reproduce it myself, but QA gave me a hard time. Are you saying

Re: [edk2-devel] [PATCH v2 16/31] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected

On 04/09/19 13:08, Anthony PERARD wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenPlatformPei/Platform.h | 5 + > OvmfPkg/XenPlatformPei/Xen.c | 7 +++ > 2 files changed, 12 insertions(+) > > diff --git

[Xen-devel] [PATCH] xl: handle PVH type in apply_global_affinity_masks again

A call site in create_domain can call it with PVH type. That site was missed during the review of 48dab9767. Reinstate PVH type in the switch. Reported-by: Julien Grall Signed-off-by: Wei Liu --- tools/xl/xl_vcpu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/xl/xl_vcpu.c

Re: [Xen-devel] [PATCH] xl: handle PVH type in apply_global_affinity_masks again

On Fri, Apr 12, 2019 at 11:03:25AM +0100, Wei Liu wrote: > A call site in create_domain can call it with PVH type. That site was > missed during the review of 48dab9767. > > Reinstate PVH type in the switch. > > Reported-by: Julien Grall > Signed-off-by: Wei Liu CC Juergen This fixes a

Re: [edk2-devel] [PATCH v2 19/31] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected

On 04/09/19 13:08, Anthony PERARD wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenPlatformPei/Platform.h | 5 + > OvmfPkg/XenPlatformPei/Xen.c | 13 + > 2 files changed, 18 insertions(+) > > diff --git

Re: [edk2-devel] [PATCH 0/4] OvmfPkg: replace MIT license blocks with SPDX IDs

On 04/10/19 14:58, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: ovmf_spdx_mit > > For , we replaced > open-coded license text blocks with "SPDX-License-Identifier"s, almost > all over the edk2 tree. > > That

[Xen-devel] [xen-unstable-smoke test] 134674: regressions - FAIL

flight 134674 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134674/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 12 guest-start fail REGR. vs. 133991 build-amd64

[Xen-devel] [libvirt test] 134587: regressions - trouble: blocked/broken/fail/pass

flight 134587 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/134587/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-pvops

Re: [edk2-devel] [PATCH v2 17/31] OvmfPkg/XenPlatformPei: Reserve hvmloader's memory only when it as runned

On 04/09/19 13:08, Anthony PERARD wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenPlatformPei/Xen.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/OvmfPkg/XenPlatformPei/Xen.c

Re: [Xen-devel] [edk2-devel] [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...

On 12/04/2019 10:33, Laszlo Ersek wrote: > On 04/09/19 13:08, Anthony PERARD wrote: >> @@ -72,7 +81,42 @@ XenGetE820Map ( >> return EFI_SUCCESS; >>} >> >> - return EFI_NOT_FOUND; >> + // >> + // Otherwise, get the E820 table from the Xen hypervisor >> + // >> + >> + if

Re: [edk2-devel] [PATCH v2 18/31] OvmfPkg/XenPlatformPei: Setup HyperPages earlier

On 04/09/19 13:08, Anthony PERARD wrote: > We are going to need to make an hypercall in order to retreive the E820 > table from the hypervisor before been able to setup the memory. > > Calling XenConnect earlier will allow to setup the XenHypercallLib > earlier to allow to make hypercalls. > >

[Xen-devel] [freebsd-master test] 134604: all pass - PUSHED

flight 134604 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/134604/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 80646d8a6d4ab70f09c8b4a732645c349d9a6a93 baseline version: freebsd

[Xen-devel] [PATCH 1/1] xen-netback: add reference from xenvif to backend_info to facilitate coredump analysis

During coredump analysis, it is not easy to obtain the address of backend_info in xen-netback. So far there are two ways to obtain backend_info: 1. Do what xenbus_device_find() does for vmcore to find the xenbus_device and then derive it from dev_get_drvdata(). 2. Extract backend_info from

Re: [edk2-devel] [PATCH v2 21/31] OvmfPkg/XenPlatformPei: Get E820 table via hypercall ...

On 04/09/19 13:08, Anthony PERARD wrote: > .. when hvmloader haven't runned before OVMF. The only way left to get > an E820 table is to ask Xen via an hypercall, the call can only be made > once so keep the result cached for later. > > Contributed-under: TianoCore Contribution Agreement 1.1 >

[Xen-devel] Commit moratorium for broken testing

Committers, as automatic testing seems to be broken at the moment please don't push any patch to staging which doesn't fix a regression or the build. Another email will be sent once the moratorium is lifted. Juergen Gross ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH] x86/altp2m: cleanup p2m_altp2m_lazy_copy

On 12/04/2019 17:39, Tamas K Lengyel wrote: > The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view > when the guest traps out due to no EPT entry being present in the active view. > Currently the function took several inputs that it didn't use and also > locked/unlocked

Re: [Xen-devel] [PATCH 2/2] RFC: x86/mm: conditionally check page_lock/page_unlock ownership

>>> On 12.04.19 at 17:02, wrote: > On Fri, Apr 12, 2019 at 8:39 AM Jan Beulich wrote: >> >>> On 12.04.19 at 15:55, wrote: >> > On Fri, Apr 12, 2019 at 6:01 AM Jan Beulich wrote: >> >> >>> On 12.04.19 at 06:29, wrote: >> >> > Patch cf4b30dca0a "Add debug code to detect illegal page_lock and

Re: [Xen-devel] [PATCH 2/2] RFC: x86/mm: conditionally check page_lock/page_unlock ownership

On Fri, Apr 12, 2019 at 9:34 AM Jan Beulich wrote: > > >>> On 12.04.19 at 17:02, wrote: > > On Fri, Apr 12, 2019 at 8:39 AM Jan Beulich wrote: > >> >>> On 12.04.19 at 15:55, wrote: > >> > On Fri, Apr 12, 2019 at 6:01 AM Jan Beulich wrote: > >> >> >>> On 12.04.19 at 06:29, wrote: > >> >> >

[Xen-devel] [PATCH] x86/altp2m: cleanup p2m_altp2m_lazy_copy

The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view when the guest traps out due to no EPT entry being present in the active view. Currently the function took several inputs that it didn't use and also locked/unlocked gfns when it didn't need to. Signed-off-by: Tamas K

Re: [Xen-devel] [PATCH 1/2] x86/mem_sharing: reorder when pages are unlocked and released

On 12/04/2019 14:41, Tamas K Lengyel wrote: > On Fri, Apr 12, 2019 at 5:55 AM Jan Beulich wrote: > On 12.04.19 at 06:29, wrote: >>> Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing" >>> introduced >>> grabbing extra references for pages that drop references tied to >>>

Re: [Xen-devel] [PATCH 2/2] RFC: x86/mm: conditionally check page_lock/page_unlock ownership

>>> On 12.04.19 at 15:55, wrote: > On Fri, Apr 12, 2019 at 6:01 AM Jan Beulich wrote: >> >>> On 12.04.19 at 06:29, wrote: >> > Patch cf4b30dca0a "Add debug code to detect illegal page_lock and >> > put_page_type >> > ordering" added extra sanity checking to page_lock/page_unlock for debug >>

Re: [Xen-devel] [PATCH 1/1] xen-netback: add reference from xenvif to backend_info to facilitate coredump analysis

From: Dongli Zhang Date: Fri, 12 Apr 2019 14:53:24 +0800 > During coredump analysis, it is not easy to obtain the address of > backend_info in xen-netback. > > So far there are two ways to obtain backend_info: > > 1. Do what xenbus_device_find() does for vmcore to find the xenbus_device > and

Re: [Xen-devel] [PATCH] x86/altp2m: cleanup p2m_altp2m_lazy_copy

On Fri, Apr 12, 2019 at 10:48 AM Andrew Cooper wrote: > > On 12/04/2019 17:39, Tamas K Lengyel wrote: > > The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view > > when the guest traps out due to no EPT entry being present in the active > > view. > > Currently the function

Re: [Xen-devel] [PATCH v5 01/15] x86/cpu: Create Hygon Dhyana architecture support file

On 2019/4/5 15:50, Jan Beulich wrote: On 04.04.19 at 18:39, wrote: On 2019/4/4 22:07, Andrew Cooper wrote: This needs the following hunk folding in which can be done on commit to avoid sending yet another version. Do you mean I need to send a individual patch for this file instead of

[Xen-devel] arndale 4.14 test flight

I have just done this: (test-lab)iwj@osstest:~/2testing.git$ flight=`OSSTEST_JOBS_ONLY='.*armhf.*' ./make-flight osstest xen-unstable commission-arndale`; echo $flight warning: nothing anointed freebsd build master i386 warning: nothing anointed freebsd build master armhf warning: nothing

[Xen-devel] [linux-4.4 test] 134598: regressions - trouble: blocked/broken/fail/pass

flight 134598 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/134598/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 broken build-arm64-xsm

[Xen-devel] [xen-unstable-smoke test] 134702: regressions - FAIL

flight 134702 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134702/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 133991 Tests which

Re: [Xen-devel] [PATCH] x86/msr: Fix fallout from mostly c/s 832c180

>>> On 11.04.19 at 20:20, wrote: > On 10/04/2019 11:24, Jan Beulich wrote: > On 09.04.19 at 19:53, wrote: >>> The series 832c1803^..f61685a6 was committed without adequate review. >>> >>> * Fix the shim build by providing a !CONFIG_HVM declaration for >>>hvm_get_guest_bndcfgs() >>> *

Re: [Xen-devel] [PATCH 1/2] core-parking: interact with runtime SMT-disabling

>>> On 11.04.19 at 21:06, wrote: > On 11/04/2019 13:45, Jan Beulich wrote: >> When disabling SMT at runtime, secondary threads should no longer be >> candidates for bringing back up in response to _PUD ACPI events. Purge >> them from the tracking array. >> >> Doing so involves adding locking to

Re: [Xen-devel] [PATCH 1/2] x86/mem_sharing: reorder when pages are unlocked and released

>>> On 12.04.19 at 06:29, wrote: > Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing" > introduced > grabbing extra references for pages that drop references tied to > PGC_allocated. > However, the way these extra references were grabbed were incorrect, resulting > in both

Re: [Xen-devel] [PATCH 1/2] x86/mem_sharing: reorder when pages are unlocked and released

On Fri, Apr 12, 2019 at 5:55 AM Jan Beulich wrote: > > >>> On 12.04.19 at 06:29, wrote: > > Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing" > > introduced > > grabbing extra references for pages that drop references tied to > > PGC_allocated. > > However, the way these

Re: [Xen-devel] [PATCH 1/2] x86/mem_sharing: reorder when pages are unlocked and released

On Fri, Apr 12, 2019 at 8:00 AM Andrew Cooper wrote: > > On 12/04/2019 14:41, Tamas K Lengyel wrote: > > On Fri, Apr 12, 2019 at 5:55 AM Jan Beulich wrote: > > On 12.04.19 at 06:29, wrote: > >>> Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing" > >>> introduced > >>>

Re: [Xen-devel] [PATCH] x86/msr: Fix fallout from mostly c/s 832c180

> -Original Message- > > > An optimising compiler which uses an object, and passes a const pointer > > to that object to a function, is permitted to retain assumptions derived > > from that state across the function call sequence point, because the ABI > > of the function states that the

Re: [edk2-devel] [PATCH v2 22/31] OvmfPkg/XenPlatformPei: Rework memory detection

On 04/09/19 13:08, Anthony PERARD wrote: > When running as a Xen PVH guest, there is no CMOS to read the memory > size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can > works without CMOS by reading the e820 table. > > Rework XenPublishRamRegions for PVH, handle the Reserve type

Re: [Xen-devel] [PATCH 2/2] RFC: x86/mm: conditionally check page_lock/page_unlock ownership

On Fri, Apr 12, 2019 at 6:01 AM Jan Beulich wrote: > > >>> On 12.04.19 at 06:29, wrote: > > Patch cf4b30dca0a "Add debug code to detect illegal page_lock and > > put_page_type > > ordering" added extra sanity checking to page_lock/page_unlock for debug > > builds > > with the assumption that

Re: [Xen-devel] [PATCH] x86/msr: Fix fallout from mostly c/s 832c180

>>> On 12.04.19 at 15:52, wrote: > On 12/04/2019 11:46, Jan Beulich wrote: >> >>> The function promising not to alter the pointed-to-object >>> includes the entire child callgraph. >>> >>> >>> The code you insisted Paul to add is: >>> >>> struct vcpu *v = cv->domain->vcpu[cv->vcpu_id]; >>> >>>

Re: [Xen-devel] [PATCH] timers: move back migrate_timers_from_cpu() invocation

>>> On 11.04.19 at 22:03, wrote: > On 11/04/2019 11:55, Jan Beulich wrote: > On 11.04.19 at 12:47, wrote: >>> On 11/04/2019 11:45, Jan Beulich wrote: @@ -648,6 +646,8 @@ static int cpu_callback( case CPU_UP_CANCELED: case CPU_DEAD: case CPU_RESUME_FAILED:

[Xen-devel] [PATCH] x86/IO-APIC: drop an unused variable from setup_IO_APIC_irqs()

Must be a left-over from earlier days. Signed-off-by: Jan Beulich --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -984,8 +984,6 @@ static void __init setup_IO_APIC_irqs(vo for (apic = 0; apic < nr_ioapics; apic++) { for (pin = 0; pin < nr_ioapic_entries[apic];

Re: [Xen-devel] [PATCH] x86/msr: Fix fallout from mostly c/s 832c180

On 12/04/2019 11:46, Jan Beulich wrote: > >> The function promising not to alter the pointed-to-object >> includes the entire child callgraph. >> >> >> The code you insisted Paul to add is: >> >> struct vcpu *v = cv->domain->vcpu[cv->vcpu_id]; >> >> which is identical to: >> >> struct vcpu *v =

Re: [Xen-devel] [PATCH 1/2] x86/mem_sharing: reorder when pages are unlocked and released

>>> On 12.04.19 at 15:41, wrote: > On Fri, Apr 12, 2019 at 5:55 AM Jan Beulich wrote: >> >>> On 12.04.19 at 06:29, wrote: >> > @@ -984,7 +976,7 @@ static int share_pages(struct domain *sd, gfn_t sgfn, >> > shr_handle_t sh, >> > * Don't change the type of rmap for the client page. */

Re: [Xen-devel] [PATCH] xl: handle PVH type in apply_global_affinity_masks again

Wei Liu writes ("[PATCH] xl: handle PVH type in apply_global_affinity_masks again"): > A call site in create_domain can call it with PVH type. That site was > missed during the review of 48dab9767. > > Reinstate PVH type in the switch. > > Reported-by: Julien Grall > Signed-off-by: Wei Liu

Re: [Xen-devel] [PATCH] x86/HVM: correctly deal with benign exceptions when combining two

>>> On 11.04.19 at 15:39, wrote: > On 11/04/2019 08:31, Jan Beulich wrote: >> Would you mind helping me make the connection between #AC >> delivery (and its emulation) and XSA-170, being about VM entry >> with non-canonical %rip? > > Ah - that wasn't the connection I was trying to make. > >

Re: [Xen-devel] [PATCH 1/1] xen-netback: add reference from xenvif to backend_info to facilitate coredump analysis

On Fri, Apr 12, 2019 at 02:53:24PM +0800, Dongli Zhang wrote: > During coredump analysis, it is not easy to obtain the address of > backend_info in xen-netback. > > So far there are two ways to obtain backend_info: > > 1. Do what xenbus_device_find() does for vmcore to find the xenbus_device >

[Xen-devel] [distros-debian-jessie test] 83925: trouble: blocked/broken

flight 83925 distros-debian-jessie real [real] http://osstest.xensource.com/osstest/logs/83925/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386

[Xen-devel] [xen-unstable-smoke test] 134696: regressions - FAIL

flight 134696 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134696/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 12 guest-start fail REGR. vs. 133991 build-amd64

Re: [Xen-devel] [PATCH v3 1/3] x86/mm: Introduce altp2m_get_gfn_type_access

On 11.04.2019 16:28, Tamas K Lengyel wrote: > On Thu, Apr 11, 2019 at 6:50 AM George Dunlap > wrote: >> >> On 4/11/19 1:17 PM, Alexandru Stefan ISAILA wrote: > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c > index b9bbb8f485..d38d7c29ca 100644 > ---

Re: [Xen-devel] [PATCH 2/2] RFC: x86/mm: conditionally check page_lock/page_unlock ownership

>>> On 12.04.19 at 06:29, wrote: > Patch cf4b30dca0a "Add debug code to detect illegal page_lock and > put_page_type > ordering" added extra sanity checking to page_lock/page_unlock for debug > builds > with the assumption that no hypervisor path ever locks two pages at once. > > This

[Xen-devel] [qemu-upstream-4.11-testing test] 134594: trouble: blocked/broken/fail/pass

flight 134594 qemu-upstream-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/134594/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken

Re: [Xen-devel] [PATCH] x86/IO-APIC: drop an unused variable from setup_IO_APIC_irqs()

On 12/04/2019 14:30, Jan Beulich wrote: > Must be a left-over from earlier days. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 134686: regressions - FAIL

flight 134686 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134686/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 12 guest-start fail REGR. vs. 133991 build-amd64

Re: [Xen-devel] [PATCH] x86/msr: Fix fallout from mostly c/s 832c180

>>> On 12.04.19 at 13:00, wrote: >> -Original Message- >> >> > An optimising compiler which uses an object, and passes a const pointer >> > to that object to a function, is permitted to retain assumptions derived >> > from that state across the function call sequence point, because the

Re: [Xen-devel] [PATCH] xen/tasklet: Fix return value truncation on arm64

>>> On 11.04.19 at 15:25, wrote: > The use of return_reg() assumes ARM's 32bit ABI. Therefore, a failure such as > -EINVAL will appear as a large positive number near 4 billion to a 64bit ARM > guest which happens to use continue_hypercall_on_cpu(). > > Introduce a new

Re: [Xen-devel] [PATCH] x86/livepatch: Fail the build if duplicate symbols exist

>>> On 11.04.19 at 21:51, wrote: > On 08/04/2019 11:53, Jan Beulich wrote: > On 08.04.19 at 12:11, wrote: >>> On 08/04/2019 10:52, Jan Beulich wrote: >>> On 05.04.19 at 23:02, wrote: > On Fri, Apr 05, 2019 at 08:26:04PM +0100, Andrew Cooper wrote: >> From: Ross Lagerwall >>

Re: [Xen-devel] [PATCH 2/2] RFC: x86/mm: conditionally check page_lock/page_unlock ownership

On Fri, Apr 12, 2019 at 8:39 AM Jan Beulich wrote: > > >>> On 12.04.19 at 15:55, wrote: > > On Fri, Apr 12, 2019 at 6:01 AM Jan Beulich wrote: > >> >>> On 12.04.19 at 06:29, wrote: > >> > Patch cf4b30dca0a "Add debug code to detect illegal page_lock and > >> > put_page_type > >> > ordering"

[Xen-devel] [xen-unstable-smoke test] 134720: regressions - FAIL

flight 134720 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134720/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 133991 Tests which

Re: [Xen-devel] Xen commit 9b0bc91b3 possibly removed too much info from README

On Thu, 11 Apr 2019 at 18:29, Wei Liu wrote: > > ... > Sure. I will write a patch. > > Wei. Couple of other things I noticed after posting the original observation, that might be of use in patching the documentation 1) The tools/Makefile has a bare PYTHON EnvVar that isn't seemingly replaced

[Xen-devel] [xen-unstable-smoke test] 134732: regressions - FAIL

flight 134732 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134732/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 133991 Tests which

[Xen-devel] [PATCH v2] x86/altp2m: cleanup p2m_altp2m_lazy_copy

The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view when the guest traps out due to no EPT entry being present in the active view. Currently the function took several inputs that it didn't use and also locked/unlocked gfns when it didn't need to. Signed-off-by: Tamas K

[Xen-devel] [xen-unstable-smoke test] 134714: regressions - FAIL

flight 134714 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134714/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 133991 Tests which

[Xen-devel] [xen-4.8-testing test] 134614: regressions - trouble: blocked/broken/fail/pass

flight 134614 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/134614/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm

[Xen-devel] [ovmf test] 134640: all pass - PUSHED

flight 134640 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/134640/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e0fd9ece26c9b84a1a756a869ff2a4525e23ab33 baseline version: ovmf

[Xen-devel] [xen-unstable-smoke bisection] complete build-amd64

branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-amd64 testid xen-build Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git 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

Re: [Xen-devel] [PATCH] x86/altp2m: cleanup p2m_altp2m_lazy_copy

On 12/04/2019 20:49, Tamas K Lengyel wrote: > On Fri, Apr 12, 2019 at 1:44 PM Andrew Cooper > wrote: >>> +p2m_lock(ap2m); >>> >>> -mfn = get_gfn_type_access(hp2m, gfn_x(gfn), , , >>> - P2M_ALLOC, _order); >>> -__put_gfn(hp2m, gfn_x(gfn)); >>> +amfn =

[Xen-devel] [xen-4.9-testing test] 134611: regressions - trouble: blocked/broken/fail/pass

flight 134611 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/134611/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken build-arm64-xsm

[Xen-devel] [PATCH] x86/boot: Don't leak the module_map allocation in __start_xen()

Ever since its introducion in c/s 436fb462 "x86/microcode: enable boot time (pre-Dom0) loading", the allocation has gone un-freed, and has its final use as part of constructing dom0. Xen already consideres it an error to have more than a single unaccounted-for module (again, logic from the same

Re: [Xen-devel] [PATCH] x86/altp2m: cleanup p2m_altp2m_lazy_copy

On Fri, Apr 12, 2019 at 1:44 PM Andrew Cooper wrote: > > On 12/04/2019 17:39, Tamas K Lengyel wrote: > > The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view > > when the guest traps out due to no EPT entry being present in the active > > view. > > Currently the function

[Xen-devel] [PATCH v2 2/2] x86/mem_sharing: replace using page_lock with our own lock

The page_lock system was not intended to be used outside the PV pagetable code. Replace its use in mem_sharing with an internal rwlock. Signed-off-by: Tamas K Lengyel Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: Roger Pau Monne --- xen/arch/x86/mm/mem_sharing.c |

[Xen-devel] [PATCH v2 1/2] x86/mem_sharing: reorder when pages are unlocked and released

Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing" introduced grabbing extra references for pages that drop references tied to PGC_allocated. However, the way these extra references were grabbed were incorrect, resulting in both share_pages and unshare_pages failing. There

Re: [Xen-devel] [PATCH] x86/altp2m: cleanup p2m_altp2m_lazy_copy

On 12/04/2019 17:39, Tamas K Lengyel wrote: > The p2m_altp2m_lazy_copy is responsible for lazily populating an altp2m view > when the guest traps out due to no EPT entry being present in the active view. > Currently the function took several inputs that it didn't use and also > locked/unlocked