[Xen-devel] [linux-next test] 134526: trouble: blocked/broken/fail/pass

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

Re: [Xen-devel] [PATCH RFC 00/49] xen: add core scheduling support

On 11/04/2019 02:34, Dario Faggioli wrote: > On Fri, 2019-03-29 at 19:16 +0100, Dario Faggioli wrote: >> On Fri, 2019-03-29 at 16:08 +0100, Juergen Gross wrote: >>> I have done some very basic performance testing: on a 4 cpu system >>> (2 cores with 2 threads each) I did a "make -j 4" for building

[Xen-devel] [PATCH 3/4] swiotlb-xen: simplify the DMA sync method implementations

Get rid of the grand multiplexer and implement the sync_single_for_cpu and sync_single_for_device methods directly, and then loop over them for the scatterlist based variants. Note that this also loses a few comments related to highlevel DMA API concepts, which have nothing to do with the swiotlb-

[Xen-devel] a few xen swiotlb cleanups

Hi all, below are a couple of cleanups for swiotlb-xen.c. They were done in preparation of eventually using the dma-noncoherent.h cache flushing hooks, but that final goal will need some major work to the arm32 code first. Until then I think these patches might be better in mainline than in my l

[Xen-devel] [PATCH 2/4] swiotlb-xen: use ->map_page to implement ->map_sg

We can simply loop over the segments and map them, removing lots of duplicate code. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 68 ++- 1 file changed, 10 insertions(+), 58 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen

[Xen-devel] [PATCH 1/4] swiotlb-xen: make instances match their method names

Just drop two pointless _attrs prefixes to make the code a little more grep-able. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 877b

[Xen-devel] [PATCH 4/4] swiotlb-xen: ensure we have a single callsite for xen_dma_map_page

Refactor the code a bit to make further changes easier. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 31 --- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 9a951504dc12..5

[Xen-devel] [xen-unstable-smoke test] 134624: regressions - trouble: blocked/broken/fail/pass

flight 134624 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134624/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-xsm 4 hos

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

>>> On 10.04.19 at 01:58, wrote: > Across the instruction writeback boundary (priority 10 around to 1), > PENDING_DBG persists, and feeds into exception considerations at > priority 2 and 4. This is why they manifest as traps, but they can be > equally thought of as faults before the fetch of the

Re: [edk2-devel] [PATCH v2 02/31] OvmfPkg: Create platform XenOvmf

On 04/10/19 20:37, Jordan Justen wrote: > On 2019-04-10 07:27:15, Laszlo Ersek wrote: >> On 04/10/19 11:48, Jordan Justen wrote: >>> On 2019-04-09 04:08:15, Anthony PERARD wrote: This is a copy of OvmfX64, removing VirtIO and some SMM. This new platform will be changed to make it wor

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

Firstly, want to say how happy I was to see the reliance on Python2 go, not least, as a Linux From Scratch builder, where Python3 is now part of the "core OS", one doesn't have to also install Python2, however, I grabbed your master branch last night (cb70a26) to try things out and still fell foul

Re: [Xen-devel] [PATCH 3/3] x86/smt: Support for enabling/disabling SMT at runtime

>>> On 03.04.19 at 12:17, wrote: > On 03/04/2019 10:33, Jan Beulich wrote: > On 02.04.19 at 21:57, wrote: >>> +if ( x86_cpu_to_apicid[cpu] & sibling_mask ) >>> +ret = cpu_up_helper(_p(cpu)); >> Shouldn't this be restricted to CPUs a sibling of which is already >> online? A

Re: [Xen-devel] [PATCH v2] x86/mem-sharing: statically initialize audit list head and lock

On 4/11/19 7:51 AM, Jan Beulich wrote: > There's no need to execute any instructions for doing so. Drop the then > effectively empty mem_sharing_init() altogether. > > Signed-off-by: Jan Beulich Acked-by: George Dunlap ___ Xen-devel mailing list Xen-

Re: [Xen-devel] [PATCH] xen-cpuid: constification

On Thu, Apr 11, 2019 at 12:53:31AM -0600, Jan Beulich wrote: > The majority of the static tables is never written to. Add const where > possible. > > Signed-off-by: Jan Beulich Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.o

Re: [Xen-devel] [PATCH 4/6] xen: don't free percpu areas during suspend

>>> On 28.03.19 at 09:03, wrote: > For core parking I wonder whether core_parking_helper() > shouldn't, first of all, invoke cpu_{up,down}_helper(). This > wouldn't be enough, though - the policy hooks need to honor > opt_smt as well. Actually no, there was no problem at the time there: With opt_

Re: [Xen-devel] [osstest test] 134608: regressions - trouble: broken/fail/pass

osstest service owner writes ("[osstest test] 134608: regressions - trouble: broken/fail/pass"): > flight 134608 osstest real [real] > http://logs.test-lab.xenproject.org/osstest/logs/134608/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not

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

On Thu, Apr 11, 2019 at 04:09:42PM +0800, Kevin Buckley wrote: > Firstly, want to say how happy I was to see the reliance on Python2 go, > not least, as a Linux From Scratch builder, where Python3 is now part > of the "core OS", one doesn't have to also install Python2, however, > > I grabbed your

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

On Wed, Apr 10, 2019 at 02:58:05PM +0200, 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

Re: [edk2-devel] [PATCH 2/4] OvmfPkg/License.txt: refresh the MIT license text and include the SPDX ID

On 4/10/19 2:58 PM, Laszlo Ersek wrote: > Refresh the MIT license text from , > and add "SPDX-License-Identifier: MIT" for easier parsing by machines. > > This follows the tree-wide adoption of "SPDX-License-Identifier"s, made > for

Re: [edk2-devel] [PATCH v2 05/31] OvmfPkg/XenOvmf: Creating an ELF header

On 04/09/19 13:08, Anthony PERARD wrote: > This header replace the embedded variable store. > > The ELF header explain to a loader to load the binary at the address > 1MB, then jump to the PVH entry point which will be created in a later > patch. > > That patch include generate_elf_header.c which

[Xen-devel] [PATCH] README: add a paragraph for specifying python interpreter

It is reported in Linux From Scratch there isn't necessarily a `python`. Add a paragraph to tell users how to specify a path to a python interpreter. Reported-by: Kevin Buckley Signed-off-by: Wei Liu --- CC: Kevin Buckley --- README | 6 ++ 1 file changed, 6 insertions(+) diff --git a/RE

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

On 11/04/2019 11:45, Jan Beulich wrote: > Commit 597fbb8be6 ("xen/timers: Fix memory leak with cpu unplug/plug") > went a little too far: Migrating timers away from a CPU being offlined > needs to heppen independent of whether it get parked or fully offlined. > > Signed-off-by: Jan Beulich > > ---

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

Commit 597fbb8be6 ("xen/timers: Fix memory leak with cpu unplug/plug") went a little too far: Migrating timers away from a CPU being offlined needs to heppen independent of whether it get parked or fully offlined. Signed-off-by: Jan Beulich --- a/xen/common/timer.c +++ b/xen/common/timer.c @@ -6

Re: [edk2-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH

On 04/09/19 13:08, Anthony PERARD wrote: > This one enter directly in 32bits (1) I probably mentioned this elsewhere, but it bears repeating (it applies to all patches): please don't start the body of the commit message mid-sentence or mid-paragraph. The body should be self-contained. > Informati

Re: [Xen-devel] [OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build

Hi Ian, On 4/10/19 4:47 PM, Ian Jackson wrote: Julien Grall writes ("Re: [OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build"): Ian are we using a different config between Jessie and Stretch? Not very [1], but we *are* using a different compiler (since we just use the

Re: [Xen-devel] [OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build

Hi, On 4/10/19 3:23 PM, Ian Jackson wrote: From: Wei Liu Empirically, on stretch armhf: drivers/gpu/host1x/cdma.c: In function `host1x_pushbuffer_init': drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of `dma_alloc_wc' from incompatible pointer type [-Werror=incompatible-poi

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

>>> 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: >> +migrate_timers_from_cpu(cpu); >> + >> if ( !park_offline_cpus && syst

[Xen-devel] [linux-3.18 test] 134563: regressions - trouble: blocked/broken/fail/pass

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

Re: [edk2-devel] [PATCH v2 07/31] OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests

On 04/09/19 13:08, Anthony PERARD wrote: > As described in the Xen PVH documentation [1], "ebx: contains the > physical memory address where the loader has placed the boot start info > structure". To have this pointer saved to be able to use it later in the > PEI phase, we allocate some space in th

Re: [edk2-devel] [PATCH v2 08/31] OvmfPkg/XenResetVector: Allow to jumpstart from either hvmloader or PVH

On 04/09/19 13:08, Anthony PERARD wrote: > This patch allows the ResetVector to be run indenpendently from build > time addresses. > > The goal of the patch is to avoid having to create RAM just below 4G > when creating a Xen PVH guest while been compatible with the way (1) s/been/being/ > hvmlo

Re: [edk2-devel] [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU

On 04/09/19 13:08, Anthony PERARD wrote: > ACPI Timer does not work in a PVH guest, but local APIC works on both > PVH and HVM. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenOvmf.dsc | 12 ++-- > 1 file changed, 6 insertion

Re: [edk2-devel] [PATCH v2 09/31] OvmfPkg/XenOvmf: use a TimerLib instance that depends only on the CPU

On 04/11/19 13:25, Laszlo Ersek wrote: > On 04/09/19 13:08, Anthony PERARD wrote: >> ACPI Timer does not work in a PVH guest, but local APIC works on both >> PVH and HVM. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Anthony PERARD >> --- >> OvmfPkg/XenOvmf.dsc |

Re: [edk2-devel] [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader

On 04/09/19 13:08, Anthony PERARD wrote: > This struct is only useful to retrieve the E820 table. The (1) please replace "this struct" with the name of the struct. > mXenHvmloaderInfo isn't used yet, but will be use in a further patch to > retrieve the E820 table. > > Also remove the unused poin

Re: [Xen-devel] [edk2-devel] [PATCH v2 10/31] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader

On 04/11/19 13:47, Laszlo Ersek wrote: > On 04/09/19 13:08, Anthony PERARD wrote: >> This struct is only useful to retrieve the E820 table. The > > (1) please replace "this struct" with the name of the struct. > >> mXenHvmloaderInfo isn't used yet, but will be use in a further patch to >> retriev

Re: [edk2-devel] [PATCH v2 11/31] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820

On 04/09/19 13:08, Anthony PERARD wrote: > Use the already checked pointer mXenHvmloaderInfo to retrieve the E820 > table produced by hvmloader. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenPlatformPei/Xen.c | 18 +

Re: [edk2-devel] [PATCH v2 12/31] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct

On 04/09/19 13:08, Anthony PERARD wrote: > Check if there's a start of the day struct provided to PVH guest, save > the ACPI RSDP address for later. > > This patch import import arch-x86/hvm/start_info.h from xen.git. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: An

Re: [edk2-devel] [PATCH v2 13/31] OvmfPkg/Library/XenPlatformLib: New library

On 04/09/19 13:08, Anthony PERARD wrote: > The purpose of XenPlatformPei is to regroup the few functions that are (1) did you mean XenPlatformLib here? > used in several places to detect if Xen is detected, and to get the > XenInfo HOB. > > Contributed-under: TianoCore Contribution Agreement 1.1

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

Hi George, Thanks for the patch, I've did some work on it and I've attached a version that suits our needs. I have a few comments/questions to you and Tamas because in v3 there was a discussion about keeping the "if ( !mfn_valid(*mfn) || *t != p2m_ram_rw )" check inside the new function or let

Re: [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist

On 04/09/19 13:08, Anthony PERARD wrote: > If the firmware have been started via the PVH entry point, a RSDP > pointer would have been provided. Use it. > > Also, use XenDetect() from the new XenPlatformLib. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Anthony PERA

Re: [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist

On 04/11/19 14:20, Laszlo Ersek wrote: > On 04/09/19 13:08, Anthony PERARD wrote: >> If the firmware have been started via the PVH entry point, a RSDP >> pointer would have been provided. Use it. >> >> Also, use XenDetect() from the new XenPlatformLib. >> >> Contributed-under: TianoCore Contributio

[Xen-devel] [xen-unstable-smoke test] 134626: regressions - trouble: blocked/broken/fail/pass

flight 134626 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134626/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-xsm 4 hos

[Xen-devel] [PATCH 0/2] core-parking: SMT-disable and section adjustments

1: interact with runtime SMT-disabling 2: adjust data/code placement Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [edk2-devel] [PATCH v2 14/31] OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist

On 04/11/19 14:23, Laszlo Ersek wrote: > On 04/11/19 14:20, Laszlo Ersek wrote: >> On 04/09/19 13:08, Anthony PERARD wrote: >>> If the firmware have been started via the PVH entry point, a RSDP >>> pointer would have been provided. Use it. >>> >>> Also, use XenDetect() from the new XenPlatformLib.

[Xen-devel] [PATCH 2/2] core-parking: adjust data/code placement

Use __init{data,}, __read_mostly, and const as far as possible. Take the liberty and also shorten the policy structure's tag name. Signed-off-by: Jan Beulich --- a/xen/common/core_parking.c +++ b/xen/common/core_parking.c @@ -29,15 +29,15 @@ static DEFINE_SPINLOCK(accounting_lock); static uint

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

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 guard accounting data in the core parking code. While adding the declaration for the lock ta

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

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 >>> --- a/xen/arch/x86/mm/p2m.c >>> +++ b/xen/arch/x86/mm/p2m.c >>> @@ -2626,6 +2626,7 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned >

Re: [Xen-devel] [PATCH v2 06/31] OvmfPkg/XenResetVector: Add new entry point for Xen PVH

On 09/04/2019 12:08, Anthony PERARD wrote: > diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm > b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm > new file mode 100644 > index 00..c4802bf4d1 > --- /dev/null > +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm > @@ -0,0 +1,47 @@ > +;--

Re: [Xen-devel] [PATCH v2 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture

On Tue, Apr 09, 2019 at 04:12:38AM +0100, Igor Druzhinin wrote: > This aperture doesn't exist in QEMU-XEN and hvmloader places BARs > in arbitrary order disregarding prefetchable bit. This makes > prefetchable and non-prefetchable BARs to follow each other that's > quite likely with PCI passthrough

Re: [Xen-devel] [PATCH v2] x86/mem-sharing: statically initialize audit list head and lock

On Thu, Apr 11, 2019 at 12:51 AM Jan Beulich wrote: > > There's no need to execute any instructions for doing so. Drop the then > effectively empty mem_sharing_init() altogether. > > Signed-off-by: Jan Beulich Acked-by: Tamas K Lengyel ___ Xen-devel

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

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

Re: [Xen-devel] [PATCH v2 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

On 09/04/2019 04:12, Igor Druzhinin wrote: > On Xen, hvmloader firmware leaves address decoding enabled for > enumerated PCI device before jumping into OVMF. OVMF seems to > expect it to be disabled and tries to size PCI BARs in several places > without disabling it which causes BAR64, for example,

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

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 arch_hypercall_tasklet_result() hook which is implemented by both arch

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

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 > >>> --- a/xen/arch/x86/mm/p2m.c > >>> +++ b/xen/arch/x86/mm/p2m.c > >>> @@ -2626,

Re: [Xen-devel] [PATCH RFC 00/49] xen: add core scheduling support

On Thu, 2019-04-11 at 09:16 +0200, Juergen Gross wrote: > On 11/04/2019 02:34, Dario Faggioli wrote: > > Also, it's Phoronix again. I don't especially love it, but I'm > > still > > working on convincing our own internal automated benchmarking tool > > (which I like a lot more :-) ) to be a good fr

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

On 11/04/2019 08:31, Jan Beulich wrote: > >>> That's also the way the XSA-156 advisory describes it. >> XSA-156 was written at a time when we both had far less authority to >> comment on the specific details. Certainly as far as I am concerned, >> the past couple of years have made a massive diffe

Re: [Xen-devel] [PATCH v2 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

On 11/04/2019 14:19, Andrew Cooper wrote: > On 09/04/2019 04:12, Igor Druzhinin wrote: >> On Xen, hvmloader firmware leaves address decoding enabled for >> enumerated PCI device before jumping into OVMF. OVMF seems to >> expect it to be disabled and tries to size PCI BARs in several places >> witho

[Xen-devel] [xen-unstable test] 134543: regressions - trouble: blocked/broken/fail/pass

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

[Xen-devel] osstest force push (Re: [osstest test] 134621: regressions - trouble: blocked/broken/fail/pass)

osstest service owner writes ("[osstest test] 134621: regressions - trouble: blocked/broken/fail/pass"): > flight 134621 osstest real [real] > http://logs.test-lab.xenproject.org/osstest/logs/134621/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which co

[Xen-devel] [xen-unstable-smoke test] 134637: regressions - trouble: blocked/broken/fail/pass

flight 134637 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134637/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken build-arm64-xsm 4 hos

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-xl-qemuu-ovmf-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-qemuu-ovmf-amd64 testid guest-saverestore Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu

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

On Wed, Apr 10, 2019 at 12:33:38PM +0200, Olaf Hering wrote: > If a domU has a qemu-xen instance attached, it is required to call qemus > "xen-save-devices-state" method. Without it, the receiving side of a PV or > PVH migration may be unable to lock the image: > > xen be: qdisk-51712: xen be: qdi

[Xen-devel] [distros-debian-wheezy test] 83921: trouble: blocked/broken

flight 83921 distros-debian-wheezy real [real] http://osstest.xensource.com/osstest/logs/83921/ 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

Re: [Xen-devel] [PATCH] AMD/IOMMU: disable previously enabled IOMMUs upon init failure

On 4/8/19 6:19 AM, Jan Beulich wrote: > If any IOMMUs were successfully initialized before encountering failure, > the successfully enabled ones should be disabled again before cleaning > up their resources. > > Move disable_iommu() next to enable_iommu() to avoid a forward > declaration, and take

Re: [Xen-devel] [PATCH v2 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing

On 11/04/2019 15:13, Igor Druzhinin wrote: > On 11/04/2019 14:19, Andrew Cooper wrote: >> On 09/04/2019 04:12, Igor Druzhinin wrote: >>> On Xen, hvmloader firmware leaves address decoding enabled for >>> enumerated PCI device before jumping into OVMF. OVMF seems to >>> expect it to be disabled and

[Xen-devel] arndales, armhf osstest capacity

In "[OSSTEST PATCH 00/62] Update to Debian stable (stretch)" I wrote: > * I experienced difficulties with the 4 Arndale devboards: high >probability guest start failures. For now I have marked those >nodes as unsuitable for use with stretch, which will, effectively, >take them out of

[Xen-devel] [xen-4.12-testing test] 134568: trouble: blocked/broken/fail/pass

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

Re: [Xen-devel] arndales, armhf osstest capacity

Hi Ian, On 4/11/19 5:51 PM, Ian Jackson wrote: In "[OSSTEST PATCH 00/62] Update to Debian stable (stretch)" I wrote: * I experienced difficulties with the 4 Arndale devboards: high probability guest start failures. For now I have marked those nodes as unsuitable for use with stretch

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

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() >> * Revert the bogus de-const'ing of the vcpu po

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

On 10/04/2019 09:28, Paul Durrant wrote: > Again, digging back in mail... > > - > [From Jan] >> +case MSR_IA32_BNDCFGS: >> +if ( !is_hvm_domain(d) || !cp->feat.mpx || >> + !hvm_set_guest_bndcfgs(v, val) ) >> +goto gp_fault; > In both cases the is_hvm_*() chec

[Xen-devel] [ovmf baseline-only test] 83922: trouble: blocked/broken

This run is configured for baseline tests only. flight 83922 ovmf real [real] http://osstest.xensource.com/osstest/logs/83922/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm

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

flight 134650 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134650/ 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 2/2] core-parking: adjust data/code placement

On 11/04/2019 13:45, Jan Beulich wrote: > Use __init{data,}, __read_mostly, and const as far as possible. > > Take the liberty and also shorten the policy structure's tag name. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel maili

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

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 guard accounting data in the core > parking

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

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 > > The binary diffing algorithm used by

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

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: >>> +migrate_timers_from_cpu(cpu); >

[Xen-devel] [linux-4.9 test] 134572: trouble: blocked/broken/fail/pass

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

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

flight 134655 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134655/ 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] [xen-unstable-smoke test] 134661: regressions - FAIL

flight 134661 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134661/ 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] livepatch-build-tools: fix section mismatch

HI all A quick bump on this, and added Andrew to the CC list since he appears to have looked at livepatch 'stuff' recently. Was this patch of any interest at all? Or just wrong? After reading patch submission guidlines, should I resend this a different way? Regards, Glenn On 4/1/19 3:28 PM

Re: [Xen-devel] livepatch-build-tools: fix section mismatch

On Fri, Apr 12, 2019 at 01:21:48PM +1200, Glenn Enright wrote: > HI all > > A quick bump on this, and added Andrew to the CC list since he appears to > have looked at livepatch 'stuff' recently. > > Was this patch of any interest at all? Or just wrong? After reading patch > submission guidlines,

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

flight 134669 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/134669/ 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] [linux-4.14 test] 134576: trouble: blocked/broken/fail/pass

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

[Xen-devel] [PATCH 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 actuall

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

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 assumption doesn't hold during memory sharing. This is onl

[Xen-devel] [PATCH] livepatch-build-tools: Detect special section group sizes

A recent xsa livepatch failed to generate due to the following message in create-diff-object.log ... /livepatch-build-tools/create-diff-object: ERROR: grant_table.o: kpatch_regenerate_special_section: 1162: group size mismatch for section .altinstructions This is similar to the issue reported an

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

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

[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 58aa509054a

[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 calls