[Xen-devel] [xen-unstable-smoke test] 113064: trouble: broken/fail/pass

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

[Xen-devel] [xen-unstable-smoke test] 113062: trouble: broken/pass

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

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

flight 113054 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113054/ 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-pvops

[Xen-devel] kernel panic with no call trace

Hello~~ I'm struggling to resolve a kernel panic problem during developing scheduler code. But I have not made any progress since I can not get any meaningful information from the serial log. When the panic occurred, always there is no call trace and only panic notification like following: (XEN)

[Xen-devel] [xen-unstable-smoke test] 113059: trouble: broken/pass

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

[Xen-devel] [ovmf baseline-only test] 72065: all pass

This run is configured for baseline tests only. flight 72065 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72065/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 56e88e9e5f980e30f28d907e0ff442e4dc8dc5de baseline

[Xen-devel] [qemu-mainline test] 113051: trouble: blocked/broken/fail/pass

flight 113051 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/113051/ 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-pvops

[Xen-devel] [xen-unstable-smoke test] 113057: trouble: broken/pass

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

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

flight 113049 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/113049/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

Re: [Xen-devel] [PATCH] xen: Drop asmlinkage everywhere

On Fri, 1 Sep 2017, Andrew Cooper wrote: > asmlinkage is defined as nothing on all architectures, and not used > consistently anywhere, even in common code. Remove it all. > > Signed-off-by: Andrew Cooper I admit I liked the asmlinkage tag because it made it easier

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

On Tue, 5 Sep 2017, Dario Faggioli wrote: > So, I now think that what I did not understand, when looking at ARM > code, was that context_switch() does indeed return, and hence we do at > least another step inside the loop, and hit the ASSERT(), which I guess > may trigger if what's in spite of the

[Xen-devel] [xen-unstable-smoke test] 113055: trouble: broken/pass

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

Re: [Xen-devel] [linux-linus test] 113048: regressions - trouble: blocked/broken/fail/pass

On 09/05/2017 03:32 PM, osstest service owner wrote: > flight 113048 linux-linus real [real] > http://logs.test-lab.xenproject.org/osstest/logs/113048/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

[Xen-devel] [linux-linus test] 113048: regressions - trouble: blocked/broken/fail/pass

flight 113048 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/113048/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 113031

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

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

Re: [Xen-devel] Next Xen ARM community call - Wednesday 13th September 2017

On Fri, 25 Aug 2017, Julien Grall wrote: > Hi all, > > I would suggest to have the next community call on Wednesday 13th September > 2017 5pm BST. Does it sound good? > > Do you have any specific topic you would like to discuss? Wednesday the 13th of September clashes with the Xilinx Embedded

Re: [Xen-devel] [PATCH] x86/traps: Fix show_page_walk() to avoid printing trailing whitespace

On Tue, Sep 05, 2017 at 05:54:54PM +0100, Andrew Cooper wrote: > This moves the L2 line to be consistent with the L3 line. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing

[Xen-devel] [BUG] x86/hvm/vioapic: 8-Bit IOREGSEL write does not work

I've seen this problem with Xen 4.6.5 from the Xubuntu 16.04 distribution and from a quick look over the current vioapic code it seems to be still present. From the IOAPIC datasheet [1]: "To reference an IOAPIC register, a byte memory write that the PIIX3 decodes for the IOAPIC loads the IOREGSEL

Re: [Xen-devel] [RFC PATCH v4] xen: credit2: provide custom option to create runqueue

On Fri, 2017-06-09 at 18:41 +0200, Dario Faggioli wrote: > Hey Praveen, > Hey, hello again! > Here we are, sorry for the delay. > So, about this patch... I haven't seen a new version (or did I perhaps miss it?). I'm asking because I do have it half done myself, and it would not take too much

Re: [Xen-devel] [PATCH v2 1/4] xen: credit2: implement utilization cap

On Thu, 2017-08-24 at 20:42 +0100, Anshul Makkar wrote: > On 8/18/17 4:50 PM, Dario Faggioli wrote: > >    > > @@ -1515,7 +1633,16 @@ static void reset_credit(const struct > > scheduler *ops, int cpu, s_time_t now, > >    * that the credit it has spent so far get accounted. > >    

[Xen-devel] [xen-unstable-smoke test] 113053: trouble: broken/pass

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

Re: [Xen-devel] [PATCH v3 5/6] xen: RCU: avoid busy waiting until the end of grace period.

On Wed, 2017-08-30 at 01:18 -0600, Jan Beulich wrote: > > > > On 29.08.17 at 18:06, wrote: > > > > On 08/22/2017 02:04 PM, Jan Beulich wrote: > > > > > > On 18.08.17 at 20:04, wrote: > > > > > > > > --- a/xen/arch/x86/cpu/mwait-idle.c > > >

[Xen-devel] [PATCH v3 3/5] ARM: ITS: Deny hardware domain access to ITS

From: Manish Jaggi This patch extends the gicv3_iomem_deny_access functionality by adding support for ITS region as well. Add function gicv3_its_deny_access. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 22 ++

[Xen-devel] [PATCH v3 2/5] ARM: ITS: Populate host_its_list from ACPI MADT Table

From: Manish Jaggi Added gicv3_its_acpi_init to update host_its_list from MADT table. For ACPI, host_its structure stores dt_node as NULL. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 26 ++

[Xen-devel] [PATCH v3 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

From: Manish Jaggi estimate_acpi_efi_size needs to be updated to provide correct size of hardware domains MADT, which now adds ITS information as well. Introducing gic_get_hwdom_madt_size. Signed-off-by: Manish Jaggi --- xen/arch/arm/domain_build.c | 7

[Xen-devel] [PATCH v3 0/5] ARM: ACPI: ITS: Add ITS Support for ACPI hardware domain

From: Manish Jaggi This patch is split into 5 patches. First two add support for updating host_its_list from ACPI MADT table. The rest patches provide support to update the hardware domain MADT table with ITS information. Changes since v2: - %s/u32/unsigned long -

[Xen-devel] [PATCH v3 1/5] ARM: ITS: Introduce common function add_to_host_its_list

From: Manish Jaggi add_to_host_its_list will update the host_its_list. This common function to be invoked from gicv3_its_dt_init and gic_v3_its_acpi_probe. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c | 32 1

[Xen-devel] [PATCH v3 5/5] ARM: ITS: Expose ITS in the MADT table

From: Manish Jaggi Add gicv3_its_make_hwdom_madt to update hwdom MADT ITS information. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 23 +++ xen/arch/arm/gic-v3.c| 1 + xen/include/asm-arm/gic_v3_its.h

Re: [Xen-devel] [PATCH 00/17] x86: emulator enhancements

Jan, I'm really sorry, but would you mind sending this again (rebased if you have it, without attachments)? My tooling is completely failing to do anything sensible with this. -George On Wed, Jun 21, 2017 at 12:23 PM, Jan Beulich wrote: > 01: support remaining AVX insns >

[Xen-devel] [PATCH] x86/traps: Fix show_page_walk() to avoid printing trailing whitespace

This moves the L2 line to be consistent with the L3 line. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu --- xen/arch/x86/x86_64/traps.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [Xen-devel] [PATCH v3] x86/emul: Fix the handling of unimplemented Grp7 instructions

Reviewed-by: Petre Pircalabu On Ma, 2017-09-05 at 09:41 +0100, Andrew Cooper wrote: > Grp7 is abnormally complicated to decode, even by x86's standards, > with > {s,l}msw being the problematic cases. > > Previously, any value which fell through the first switch

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

flight 113047 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113047/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 7 xen-boot fail REGR. vs. 113024 Regressions which

Re: [Xen-devel] [PATCH] xen: reset creation_finished flag on soft reset

Paul Durrant writes: >> Paul Durrant writes: >> >> > >> > I wonder whether the easiest thing to do would be to modify qemu trad >> > to do explicit ioreq server creation? It's really not that much >> > code-change... 20-30 lines or so. >> >> I

Re: [Xen-devel] [PATCH v4 01/13] libxl: add generic function to add device

On Tue, Sep 5, 2017 at 2:47 PM, Wei Liu wrote: > On Tue, Jul 18, 2017 at 05:25:18PM +0300, Oleksandr Grytsov wrote: >> From: Oleksandr Grytsov >> >> Add libxl__device_add to simple write XenStore device conifg >> and libxl__device_add_async to

[Xen-devel] [PATCH v4 2/2] xl: Register the AER event handler to handle AER errors

When a guest is created, register the AER event handler to handle the AER errors. When an AER error occurs, the handler will forcibly remove the erring PCIe device from the guest. Signed-off-by: Venu Busireddy --- tools/xl/xl_vmcontrol.c | 9 + 1 file changed,

[Xen-devel] [PATCH v4 0/2] Containing AER unrecoverable errors

This patch set is part of a set of patches that together allow containment of unrecoverable AER errors from PCIe devices assigned to guests in passthrough mode. The containment is achieved by forcibly removing the erring PCIe device from the guest. The original xen-pciback patch corresponding to

[Xen-devel] [PATCH v4 1/2] libxl: Implement the handler to handle unrecoverable AER errors

Implement the callback function to handle unrecoverable AER errors, and also the public APIs that can be used to register/unregister the handler. When an AER error occurs, the handler will forcibly remove the erring PCIe device from the guest. Signed-off-by: Venu Busireddy

Re: [Xen-devel] [Xen-users] UEFI Secure Boot Xen 4.9

On Mon, Sep 4, 2017 at 6:40 AM, Daniel Kiper wrote: > On Wed, Aug 30, 2017 at 10:16:23AM -0600, Tamas K Lengyel wrote: >> On Tue, Aug 29, 2017 at 2:01 PM, Daniel Kiper >> wrote: >> > Hey Tamas, >> > >> > Sorry for late reply. I was on vacation.

Re: [Xen-devel] [PATCH v9 1/2] x86emul: New return code for unimplemented instruction

On Ma, 2017-09-05 at 09:46 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 05.09.17 at 17:23, wrote: > > On Lu, 2017-09-04 at 23:42 -0600, Jan Beulich wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @@ -5177,7 +5177,7 @@ x86_emulate(

Re: [Xen-devel] [PATCH v6] common/vm_event: Initialize vm_event lists on domain creation

On Wed, Aug 30, 2017 at 3:04 AM, Alexandru Isaila wrote: > The patch splits the vm_event into three structures:vm_event_share, > vm_event_paging, vm_event_monitor. The allocation for the > structure is moved to vm_event_enable so that it can be > allocated/init when

Re: [Xen-devel] [PATCH] x86: introduce and use setup_force_cpu_cap()

On 05/09/17 14:22, Jan Beulich wrote: > For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd > need to clone the respective hack used for CPUID_FAULTING. Introduce an > inverse of setup_clear_cpu_cap() instead, but let clearing of features > overrule forced setting of them. > >

Re: [Xen-devel] [RFC PATCH 1/4] arm/monitor: Introduce monitoring of single-step events

> diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h > index 7567be66bd..66c7fe14fe 100644 > --- a/xen/include/asm-arm/monitor.h > +++ b/xen/include/asm-arm/monitor.h > @@ -57,12 +57,15 @@ static inline uint32_t > arch_monitor_get_capabilities(struct domain *d) > { >

Re: [Xen-devel] [PATCH 4/4] DEPS handling: Remove absolute paths from references to cwd

>>> On 05.09.17 at 17:32, wrote: > Jan Beulich writes ("Re: [PATCH 4/4] DEPS handling: Remove absolute paths > from references to cwd"): >> On 04.09.17 at 18:46, wrote: >> > +%.d2: %.d >> >> Wouldn't it be better to use .%.d2 and .%.d here?

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

On Mon, 2017-09-04 at 09:46 +0100, George Dunlap wrote: > On 09/02/2017 04:39 PM, Julien Grall wrote: > > > > If I am not mistaken the hypervisor stack is per-vCPU. So when you > > move the > > vCPU to another pCPU, the stack will be moved. > > This means the smp_processor_id() will return a

Re: [Xen-devel] [PATCH v9 1/2] x86emul: New return code for unimplemented instruction

>>> On 05.09.17 at 17:23, wrote: > On Lu, 2017-09-04 at 23:42 -0600, Jan Beulich wrote: >> > > >> > > > >> > > > @@ -5177,7 +5177,7 @@ x86_emulate( >> > > > goto done; >> > > > break; >> > > > default: >> > > > -goto

Re: [Xen-devel] [PATCH v2] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()

On 09/05/2017 11:14 AM, Jan Beulich wrote: On 05.09.17 at 16:54, wrote: >> On 09/05/2017 10:42 AM, Boris Ostrovsky wrote: > @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages( > * guest can control its own visibility of/through the

Re: [Xen-devel] [PATCH 4/4] DEPS handling: Remove absolute paths from references to cwd

Jan Beulich writes ("Re: [PATCH 4/4] DEPS handling: Remove absolute paths from references to cwd"): > On 04.09.17 at 18:46, wrote: > > +%.d2: %.d > > Wouldn't it be better to use .%.d2 and .%.d here? Perhaps. That makes the assumption that nothing anywhere adds

Re: [Xen-devel] [PATCH v9 1/2] x86emul: New return code for unimplemented instruction

On Lu, 2017-09-04 at 23:42 -0600, Jan Beulich wrote: > > > > > > > > > > > @@ -5177,7 +5177,7 @@ x86_emulate( > > > > goto done; > > > > break; > > > > default: > > > > -goto cannot_emulate; > > > > +goto unimplemented_insn; > > >

Re: [Xen-devel] [PATCH v2] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()

>>> On 05.09.17 at 16:54, wrote: > On 09/05/2017 10:42 AM, Boris Ostrovsky wrote: @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages( * guest can control its own visibility of/through the cache. */

Re: [Xen-devel] [PATCH v5 07/11] pci: add support to size ROM BARs to pci_size_mem_bar

>>> On 14.08.17 at 16:28, wrote: > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -594,15 +594,18 @@ static int iommu_remove_device(struct pci_dev *pdev); > > int pci_size_mem_bar(unsigned int seg, unsigned int bus, unsigned int slot, >

[Xen-devel] [xen-unstable-smoke test] 113052: trouble: broken/pass

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

Re: [Xen-devel] [PATCH v5 06/11] pci: split code to size BARs from pci_add_device

>>> On 14.08.17 at 16:28, wrote: > So that it can be called from outside in order to get the size of regular PCI > BARs. This will be required in order to map the BARs from PCI devices into PVH > Dom0 p2m. > > Signed-off-by: Roger Pau Monné

Re: [Xen-devel] [PATCH v5 05/11] mm: move modify_identity_mmio to global file and drop __init

>>> On 14.08.17 at 16:28, wrote: > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -1465,6 +1465,46 @@ int prepare_ring_for_helper( > return 0; > } > > +#if defined(CONFIG_HAS_PCI) #ifdef please. > +int modify_mmio(struct domain *d, gfn_t gfn, mfn_t mfn,

Re: [Xen-devel] [PATCH v5 04/11] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

>>> On 14.08.17 at 16:28, wrote: > --- a/xen/arch/x86/physdev.c > +++ b/xen/arch/x86/physdev.c > @@ -559,6 +559,15 @@ ret_t do_physdev_op(int cmd, > XEN_GUEST_HANDLE_PARAM(void) arg) > > ret = pci_mmcfg_reserved(info.address, info.segment, >

Re: [Xen-devel] [PATCH v2] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()

On 09/05/2017 10:42 AM, Boris Ostrovsky wrote: >>> @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages( >>> * guest can control its own visibility of/through the cache. >>> */ >>> flush_page_to_ram(page_to_mfn([i]), !(memflags & >>> MEMF_no_icache_flush));

Re: [Xen-devel] [PATCH v2] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()

>>> On 05.09.17 at 16:42, wrote: >>> @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages( >>> * guest can control its own visibility of/through the cache. >>> */ >>> flush_page_to_ram(page_to_mfn([i]), !(memflags & >

Re: [Xen-devel] [PATCH 4/4] DEPS handling: Remove absolute paths from references to cwd

>>> On 04.09.17 at 18:46, wrote: > In some directories we use gcc on source files elsewhere, to generate > a .o here in the current directory. Eg in tools/libxl/, >gcc -I -o build.o /path/to/libacpi/build.c > We pass -MMD and -MF options to generate a .d file right

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On 05/09/17 16:31, Waiman Long wrote: > On 09/05/2017 10:24 AM, Waiman Long wrote: >> On 09/05/2017 10:18 AM, Juergen Gross wrote: >>> On 05/09/17 16:10, Waiman Long wrote: On 09/05/2017 09:24 AM, Juergen Gross wrote: > There are cases where a guest tries to switch spinlocks to bare metal

Re: [Xen-devel] [PATCH v2] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()

>> @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages( >> * guest can control its own visibility of/through the cache. >> */ >> flush_page_to_ram(page_to_mfn([i]), !(memflags & >> MEMF_no_icache_flush)); >> - >> -if ( !(memflags & MEMF_no_scrub)

[Xen-devel] [ovmf baseline-only test] 72063: all pass

This run is configured for baseline tests only. flight 72063 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72063/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 302860bfc467c72bdba91af021a44e20789601dc baseline

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On 09/05/2017 10:24 AM, Waiman Long wrote: > On 09/05/2017 10:18 AM, Juergen Gross wrote: >> On 05/09/17 16:10, Waiman Long wrote: >>> On 09/05/2017 09:24 AM, Juergen Gross wrote: There are cases where a guest tries to switch spinlocks to bare metal behavior (e.g. by setting

Re: [Xen-devel] [PATCH v2] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()

>>> On 05.09.17 at 16:11, wrote: > I couldn't convince myself that just marking the head as PGC_state_inuse > under the lock is safe, mostly because of how MCE handler may write the > state while the allocator is walking (lock-free) the buddy. Good point. > @@

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On 09/05/2017 10:18 AM, Juergen Gross wrote: > On 05/09/17 16:10, Waiman Long wrote: >> On 09/05/2017 09:24 AM, Juergen Gross wrote: >>> There are cases where a guest tries to switch spinlocks to bare metal >>> behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this >>> has the

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On 09/05/2017 10:08 AM, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 10:02:57AM -0400, Waiman Long wrote: >> On 09/05/2017 09:24 AM, Juergen Gross wrote: >>> +static inline bool native_virt_spin_lock(struct qspinlock *lock) >>> +{ >>> + if (!static_cpu_has(X86_FEATURE_HYPERVISOR)) >>> +

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On 05/09/17 16:10, Waiman Long wrote: > On 09/05/2017 09:24 AM, Juergen Gross wrote: >> There are cases where a guest tries to switch spinlocks to bare metal >> behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this >> has the downside of falling back to unfair test and set scheme

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On 09/05/2017 09:24 AM, Juergen Gross wrote: > There are cases where a guest tries to switch spinlocks to bare metal > behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this > has the downside of falling back to unfair test and set scheme for > qspinlocks due to virt_spin_lock()

[Xen-devel] [PATCH v2] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()

Instead, preserve PGC_need_scrub bit when setting PGC_state_inuse state while still under the lock and clear those pages later. Note that we still need to grub the lock when clearing PGC_need_scrub bit since count_info might be updated during MCE handling in mark_page_offline(). Signed-off-by:

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On Tue, Sep 05, 2017 at 10:02:57AM -0400, Waiman Long wrote: > On 09/05/2017 09:24 AM, Juergen Gross wrote: > > +static inline bool native_virt_spin_lock(struct qspinlock *lock) > > +{ > > + if (!static_cpu_has(X86_FEATURE_HYPERVISOR)) > > + return false; > > + > > I think you can

Re: [Xen-devel] [PATCH v2] x86emul: correct EVEX decoding

On 05/09/17 14:56, Jan Beulich wrote: > While these are latent issues only for now, correct them right away: > - unnamed (in the SDM) EVEX bits need to be set/clear respectively > - EVEX.V' (called RX in our code) needs to uniformly be 1 in non-64-bit > modes, > - EXEX.R' (called R in our code)

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On 09/05/2017 09:24 AM, Juergen Gross wrote: > There are cases where a guest tries to switch spinlocks to bare metal > behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this > has the downside of falling back to unfair test and set scheme for > qspinlocks due to virt_spin_lock()

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On 05/09/17 15:55, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 03:24:43PM +0200, Juergen Gross wrote: >> diff --git a/arch/x86/include/asm/qspinlock.h >> b/arch/x86/include/asm/qspinlock.h >> index 48a706f641f2..fbd98896385c 100644 >> --- a/arch/x86/include/asm/qspinlock.h >> +++

[Xen-devel] [PATCH v2] x86emul: correct EVEX decoding

While these are latent issues only for now, correct them right away: - unnamed (in the SDM) EVEX bits need to be set/clear respectively - EVEX.V' (called RX in our code) needs to uniformly be 1 in non-64-bit modes, - EXEX.R' (called R in our code) is uniformly being ignored in non-64-bit

Re: [Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

On Tue, Sep 05, 2017 at 03:24:43PM +0200, Juergen Gross wrote: > diff --git a/arch/x86/include/asm/qspinlock.h > b/arch/x86/include/asm/qspinlock.h > index 48a706f641f2..fbd98896385c 100644 > --- a/arch/x86/include/asm/qspinlock.h > +++ b/arch/x86/include/asm/qspinlock.h > @@ -17,6 +17,25 @@

Re: [Xen-devel] [PATCH] x86emul: correct EVEX register extension bit handling for non-64-bit modes

>>> On 05.09.17 at 15:36, wrote: On 05.09.17 at 15:07, wrote: >> On 10/07/17 08:25, Jan Beulich wrote: >> What about the opcode independent cases? We should check that the two >> MBZ bits (currently an anonymous bitfield) are zero, and the MBS

Re: [Xen-devel] [PATCH] x86emul: correct VEX.W handling for non-64-bit VPINSRD

On 10/07/17 08:24, Jan Beulich wrote: > Going though the XED commits from the last couple of months made me > notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non- > 64-bit modes, leading to an insertion of stray 32-bits of zero in case > the original instruction had the bit set.

Re: [Xen-devel] [PATCH] x86emul: correct EVEX register extension bit handling for non-64-bit modes

>>> On 05.09.17 at 15:07, wrote: > On 10/07/17 08:25, Jan Beulich wrote: >> While these are latent issues only for now, correct them right away: >> - EVEX.V' (called RX in our code) needs to uniformly be 1, >> - EXEX.R' (called R in our code) is uniformly being ignored.

Re: [Xen-devel] [PATCH v3] x86/HVM: don't #GP/#SS on wrapping virt->linear translations

>>> On 05.09.17 at 14:26, wrote: > On 10/07/17 11:39, Jan Beulich wrote: >> Real hardware wraps silently in most cases, so we should behave the >> same. Also split real and VM86 mode handling, as the latter really >> ought to have limit checks applied. >> >>

[Xen-devel] [PATCH 4/4] paravirt,xen: correct xen_nopvspin case

With the boot parameter "xen_nopvspin" specified a Xen guest should not make use of paravirt spinlocks, but behave as if running on bare metal. This is not true, however, as the qspinlock code will fall back to a test-and-set scheme when it is detecting a hypervisor. In order to avoid this set

[Xen-devel] [PATCH 3/4] paravirt: add virt_spin_lock pvops function

There are cases where a guest tries to switch spinlocks to bare metal behavior (e.g. by setting "xen_nopvspin" boot parameter). Today this has the downside of falling back to unfair test and set scheme for qspinlocks due to virt_spin_lock() detecting the virtualized environment. Make

[Xen-devel] [PATCH 1/4] paravirt: add generic _paravirt_false() function

Add a _paravirt_false() default function returning always false which can be used for cases where a boolean pvops replacement should just say "no". Signed-off-by: Juergen Gross --- arch/x86/include/asm/paravirt_types.h | 2 ++ arch/x86/kernel/paravirt.c| 7 +++

[Xen-devel] [PATCH 0/4] make virt_spin_lock() a pvops function

With virt_spin_lock() being a pvops function the bare metal case can be optimized by patching the call away completely. In case a kernel running as a guest it can decide whether to use paravitualized spinlocks, the current fallback to the unfair test-and-set scheme, or to mimic the bare metal

[Xen-devel] [PATCH 2/4] paravirt: switch vcpu_is_preempted to use _paravirt_false() on bare metal

Instead of special casing pv_lock_ops.vcpu_is_preempted when patching use _paravirt_false() on bare metal. Signed-off-by: Juergen Gross --- arch/x86/kernel/paravirt-spinlocks.c | 14 +- arch/x86/kernel/paravirt_patch_32.c | 10 --

Re: [Xen-devel] [PATCH] libxc/bitops: correct comment for bitmap_size

On Tue, Sep 05, 2017 at 11:03:38AM +0200, Olaf Hering wrote: > The returned value represents now units of bytes instead of longs. > > Fixes commit 11d0044a16 ("tools/libxc: Modify bitmap operations to take void > pointers") > > Signed-off-by: Olaf Hering Acked-by: Wei Liu

[Xen-devel] [PATCH] x86: introduce and use setup_force_cpu_cap()

For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd need to clone the respective hack used for CPUID_FAULTING. Introduce an inverse of setup_clear_cpu_cap() instead, but let clearing of features overrule forced setting of them. XEN_SMAP being wrong post-boot is a problem

Re: [Xen-devel] [PATCH v2 3/6] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

On Sat, Sep 02, 2017 at 01:56:35AM +0800, Zhongze Liu wrote: > 2017-09-02 0:03 GMT+08:00 Wei Liu : > > On Sun, Aug 27, 2017 at 04:36:12PM +0800, Zhongze Liu wrote: > >> Add the parsing utils for the newly introduced libxl_static_sshm struct > >> to the libxl/libxlu_* family.

Re: [Xen-devel] [PATCH] x86emul: correct EVEX register extension bit handling for non-64-bit modes

On 10/07/17 08:25, Jan Beulich wrote: > While these are latent issues only for now, correct them right away: > - EVEX.V' (called RX in our code) needs to uniformly be 1, > - EXEX.R' (called R in our code) is uniformly being ignored. > > Signed-off-by: Jan Beulich Those changes

Re: [Xen-devel] [PATCH v4 13/13] libxl: make pci and usb setdefault function generic

On Tue, Jul 18, 2017 at 05:25:30PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Due to changes in device framework setdefault function > should have same format. Otherwise calling devicetype > set_default causes segfault. > > Signed-off-by: Oleksandr

Re: [Xen-devel] [PATCH v4 12/13] libxl: remove unneeded DEVICE_ADD macro

On Tue, Jul 18, 2017 at 05:25:29PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v4 11/13] libxl: change vtpm to use generec add function

On Tue, Jul 18, 2017 at 05:25:28PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v4 03/13] libxl: add vdispl device

On Tue, Sep 05, 2017 at 01:58:53PM +0100, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH v4 03/13] libxl: add vdispl device"): > > > +rc = snprintf(connector_path, 128, "%s/%d", path, > > > info->num_connectors); > > Why not use GCSPRINTF ? These statically sized buffers etc. are an >

Re: [Xen-devel] [PATCH v4 10/13] libxl: change nic to use generec add function

On Tue, Jul 18, 2017 at 05:25:27PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Signed-off-by: Oleksandr Grytsov > diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c > index dd07a6c..16a6c8c 100644 > ---

Re: [Xen-devel] [PATCH v4 09/13] libxl: change disk to use generic getting list functions

On Tue, Jul 18, 2017 at 05:25:26PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > [...] > /* > * Insert a CD-ROM device. A device corresponding to disk must already > diff --git a/tools/libxl/libxl_checkpoint_device.c >

Re: [Xen-devel] [PATCH v4 03/13] libxl: add vdispl device

Wei Liu writes ("Re: [PATCH v4 03/13] libxl: add vdispl device"): > > +rc = snprintf(connector_path, 128, "%s/%d", path, > > info->num_connectors); Why not use GCSPRINTF ? These statically sized buffers etc. are an invitation to bugs. Ian. ___

Re: [Xen-devel] [PATCH v4 08/13] libxl: change vfb to use generec add function

On Tue, Jul 18, 2017 at 05:25:25PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v4 07/13] libxl: change vkb to use generec add function

On Tue, Jul 18, 2017 at 05:25:24PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Signed-off-by: Oleksandr Grytsov Acked-by: Wei Liu ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v4 06/13] libxl: change p9 to use generec add function

On Tue, Jul 18, 2017 at 05:25:23PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Signed-off-by: Oleksandr Grytsov This needs rebasing. ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v4 03/13] libxl: add vdispl device

On Tue, Jul 18, 2017 at 05:25:20PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Signed-off-by: Oleksandr Grytsov > --- > tools/libxl/Makefile | 2 +- > tools/libxl/libxl.h | 24 +++ >

Re: [Xen-devel] [PATCH] x86emul: correct VEX.L handling for VCVT{, T}S{S, D}2SI

On 10/07/17 08:24, Jan Beulich wrote: > Recent changes to the SDM (and XED) have made clear that older hardware > raising #UD when the bit is set was really an erratum. Generalize the > so far AMD-only override. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

[Xen-devel] [qemu-mainline test] 113044: regressions - trouble: blocked/broken/fail/pass

flight 113044 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/113044/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-stop fail REGR. vs. 113036

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

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

  1   2   >