Re: [Xen-devel] [PATCH v4] xen/arm: Add a clock property

Hi Michael, Stefano and Julien, On 22.07.2016 03:16, Stefano Stabellini wrote: On Thu, 21 Jul 2016, Michael Turquette wrote: Quoting Stefano Stabellini (2016-07-14 03:38:04) On Thu, 14 Jul 2016, Dirk Behme wrote: On 13.07.2016 23:03, Michael Turquette wrote: Quoting Dirk Behme (2016-07-13

[Xen-devel] [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

The current VBD layer reserves buffer space for each attached device based on three statically configured settings which are read at boot time. * max_indirect_segs: Maximum amount of segments. * max_ring_page_order: Maximum order of pages to be used for the shared ring. * max_queues: Maximum of

[Xen-devel] [PATCH v3] xen: credit2: issues in csched2_cpu_pick(), when tracing is enabled.

In fact, when not finding a suitable runqueue where to place a vCPU, and hence using a fallback, we either: - don't issue any trace record (while we should, at least, output the chosen pcpu), - risk underruning when accessing the runqueues array, while preparing the trace record. Fix both

[Xen-devel] [qemu-mainline baseline-only test] 66814: trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 66814 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66814/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

> What other debug info can help figure out this specific problem? I found this post with some suggestions and additional references Troubleshooting UEFI related problems https://www.qubes-os.org/doc/uefi-troubleshooting/ I tried different combinations of /mapbs, /noexitboot on the

Re: [Xen-devel] [PATCH 22/22] xen/arm: p2m: Pass the p2m in parameter rather the domain when it is possible

On Wed, 20 Jul 2016, Julien Grall wrote: > Some p2m functions do not care about the domain except to get the > associate p2m. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > xen/arch/arm/p2m.c | 16 +++- > 1 file

Re: [Xen-devel] [PATCH 21/22] xen/arm: p2m: Replace flush_tlb_domain by p2m_flush_tlb

On Wed, 20 Jul 2016, Julien Grall wrote: > The function to flush the TLBs for a given p2m does not need to know about > the domain. So pass directly the p2m in parameter. > > At the same time rename the function to p2m_flush_tlb to match the > parameter change. > > Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH 20/22] xen/arm: Don't export flush_tlb_domain

On Wed, 20 Jul 2016, Julien Grall wrote: > The function flush_tlb_domain is not used outside of the file where it > has been declared. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > xen/arch/arm/p2m.c | 2 +- >

Re: [Xen-devel] [PATCH 19/22] xen/arm: p2m: Inline p2m_load_VTTBR into p2m_restore_state

On Wed, 20 Jul 2016, Julien Grall wrote: > p2m_restore_state is the last caller of p2m_load_VTTBR and already check > if the vCPU does not belong to the idle domain. > > Note that it is likely possible to remove some isb in the function > p2m_restore_state, however this is not the purpose of this

Re: [Xen-devel] [PATCH 17/22] xen/arm: p2m: Don't need to restore the state for an idle vCPU.

On Wed, 20 Jul 2016, Julien Grall wrote: > The function p2m_restore_state could be called with an idle vCPU in > arguments (when called by construct_dom0). However, we will never return > to EL0/EL1 in this case, so it is not necessary to restore the p2m > registers. > > Signed-off-by: Julien

Re: [Xen-devel] [PATCH 16/22] xen/arm: p2m: Move the vttbr field from arch_domain to p2m_domain

On Wed, 20 Jul 2016, Julien Grall wrote: > The field vttbr holds the base address of the translation table for > guest. Its value will depends on how the p2m has been initialized and > will only be used by the code code. ^ code code? > So move the field from

Re: [Xen-devel] [PATCH 15/22] xen/arm: Don't call p2m_alloc_table from arch_domain_create

On Wed, 20 Jul 2016, Julien Grall wrote: > The p2m root table does not need to be allocate separately. > > Also remove unnecessary fields initialization as the structure is already > memset to 0 and the fields will be override by p2m_alloc_table. ^ overridden

Re: [Xen-devel] [PATCH 14/22] xen/arm: p2m: Switch the p2m lock from spinlock to rwlock

On Wed, 20 Jul 2016, Julien Grall wrote: > P2M reads do not require to be serialized. This will add contention > when PV drivers are using multi-queue because parallel grant > map/unmaps/copies will happen on DomU's p2m. > > Signed-off-by: Julien Grall Reviewed-by: Stefano

Re: [Xen-devel] [PATCH 13/22] xen/arm: p2m: Introduce p2m_{read, write}_{, un}lock helpers

On Wed, 20 Jul 2016, Julien Grall wrote: > Some functions in the p2m code do not require to modify the P2M code. > Document it by introducing separate helpers to lock the p2m. > > This patch does not change the lock. This will be done in a subsequent > patch. > > Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH 12/22] xen/arm: p2m: Remove unnecessary locking

On Wed, 20 Jul 2016, Julien Grall wrote: > The p2m is not yet in use when p2m_init and p2m_allocate_table are > called. Furthermore the p2m is not used anymore when p2m_teardown is > called. So taking the p2m lock is not necessary. > > Signed-off-by: Julien Grall

Re: [Xen-devel] [PATCH 11/22] xen/arm: p2m: Find the memory attributes based on the p2m type

On Wed, 20 Jul 2016, Julien Grall wrote: > Currently, mfn_to_p2m_entry is relying on the caller to provide the > correct memory attribute and will deduce the sharability based on it. > > Some of the callers, such as p2m_create_table, are using same memory > attribute regardless the underlying p2m

[Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

I'm running Xen-4.7.0_08-452 + linux kernel 4.7.0-4.g89a2ada-default on X86_64 UEFI hardware. If I boot without Xen hypervisor enabled it boots fine. If I boot with Xen enabled it PANICs: (XEN) [2016-07-26 22:05:33] Hardware Dom0 crashed: rebooting machine in 5 seconds.

Re: [Xen-devel] [PATCH 10/22] xen/arm: p2m: Differentiate cacheable vs non-cacheable MMIO

On Wed, 20 Jul 2016, Julien Grall wrote: > Currently, the p2m type p2m_mmio_direct is used to map in stage-2 > cacheable MMIO (via map_regions_rw_cache) and non-cacheable one (via > map_mmio_regions). The p2m code is relying on the caller to give the > correct memory attribute. > > In a follow-up

Re: [Xen-devel] [PATCH 09/22] xen/arm: p2m: Use a whitelist rather than blacklist in get_page_from_gfn

On Wed, 20 Jul 2016, Julien Grall wrote: > Currently, the check in get_page_from_gfn is using a blacklist. This is > very fragile because we may forgot to update the check when a new p2m > type is added. > > To avoid any possible issue, use a whitelist. All type backed by a RAM > page can could

Re: [Xen-devel] [PATCH v8] x86/mem-sharing: mem-sharing a range of memory

On 26/07/2016 16:49, George Dunlap wrote: > On Tue, Jul 26, 2016 at 4:22 PM, Tamas K Lengyel > wrote: >> On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap >> wrote: >>> On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel >>>

Re: [Xen-devel] [PATCH 08/22] xen/arm: p2m: Simplify p2m type check by using bitmask

On Wed, 20 Jul 2016, Julien Grall wrote: > The resulting assembly code for the macros is much simpler and will > never contain more than one instruction branch. > > The idea is taken from x86 (see include/asm-x86/p2m.h). Also move the > two helpers earlier to keep all the p2m type definitions

Re: [Xen-devel] Xen 4.8 Development Update

On Thu, Jul 21, 2016 at 05:07:23PM +0100, George Dunlap wrote: > > > > == Toolstack == > > > > * Make ACPI builder available to components other than hvmloader > > - Boris Ostrovsky > > > > * Libxl PVSCSI support > > - Olaf Hering > > > > * HVM USB passthrough > > - George Dunlap

Re: [Xen-devel] [PATCH 07/22] xen/arm: p2m: Use p2m_is_foreign in get_page_from_gfn to avoid open coding

On Wed, 20 Jul 2016, Julien Grall wrote: > No functional change. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > xen/include/asm-arm/p2m.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [Xen-devel] [PATCH 06/22] xen/arm: p2m: Use the typesafe MFN in mfn_to_p2m_entry

On Wed, 20 Jul 2016, Julien Grall wrote: > Signed-off-by: Julien Grall > --- > xen/arch/arm/p2m.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c > index d82349c..99be9be 100644 > ---

Re: [Xen-devel] [PATCH 05/22] xen/arm: p2m: Clean-up mfn_to_p2m_entry

On Wed, 20 Jul 2016, Julien Grall wrote: > The physical address is computed from the machine frame number, so > checking if the physical address is page aligned is pointless. > > Furthermore, directly assigned the MFN to the corresponding field in the > entry rather than converting to a physical

Re: [Xen-devel] [PATCH V3 0/4] Change fixed mmio handlers to a variable number

On Wed, 20 Jul 2016, Shanker Donthineni wrote: > The maximum number of mmio handlers that are allowed is limited to > a macro MAX_IO_HANDLER(16), which is not enough for supporting per CPU > Redistributor regions. We need at least MAX_IO_HANDLER+CONFIG_NR_CPUS > mmio handlers in order to support

Re: [Xen-devel] [PATCH V3 3/4] xen/arm: io: Use binary search for mmio handler lookup

Hi Shanker, On 20/07/2016 15:00, Shanker Donthineni wrote: As the number of I/O handlers increase, the overhead associated with linear lookup also increases. The system might have maximum of 144 (assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario, it would require 144 iterations

Re: [Xen-devel] [PATCH V3 4/4] arm/vgic: Change fixed number of mmio handlers to variable number

Hi Shanker, On 20/07/2016 15:00, Shanker Donthineni wrote: Compute the number of mmio handlers that are required for vGICv3 and vGICv2 emulation drivers in vgic_v3_init()/vgic_v2_init(). Augment this variable number of mmio handers to a fixed number MAX_IO_HANDLER s/handers/handlers/ and

[Xen-devel] [linux-3.18 test] 99698: regressions - FAIL

flight 99698 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/99698/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 96188

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

On Tue, 26 Jul 2016, Vitaly Kuznetsov wrote: > David Vrabel writes: > > > On 26/07/16 13:30, Vitaly Kuznetsov wrote: > >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In > >> particular, when we crash on a secondary vCPU we may want to do kdump > >> and

[Xen-devel] [linux-4.1 test] 99701: regressions - FAIL

flight 99701 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/99701/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-build fail REGR. vs. 96211

Re: [Xen-devel] [PATCH -v3 1/1] ratelimit: Implement rate limit for credit2 scheduler Rate limit assures that a vcpu will execute for a minimum amount of time before being put at the back of a queue o

On Mon, 2016-07-25 at 17:12 +0100, Anshul Makkar wrote: > It introduces context-switch rate-limiting. The patch enables the VM > to batch > its work and prevents the system from spending most of its time in > context > switches because of a VM that is waking/sleeping at high rate. > > ratelimit

[Xen-devel] [PATCH] x86/hap: use the right cache attributes when MTRR is disabled

Currently the code that calculates the cache attributes of the HAP page tables assume that if MTRR are disabled the memory type is UC, this can cause issues if MTRR are never enabled because the guest only plans to use PAT. In order to solve this modify epte_get_entry_emt so that is takes into

Re: [Xen-devel] [PATCH v2 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On Tue, Jul 26, 2016 at 04:58:10PM +0800, Bob Liu wrote: > > On 07/26/2016 04:44 PM, Roger Pau Monné wrote: > > On Tue, Jul 26, 2016 at 01:19:37PM +0800, Bob Liu wrote: > >> The current VBD layer reserves buffer space for each attached device based > >> on > >> three statically configured

Re: [Xen-devel] [PATCH v8] x86/mem-sharing: mem-sharing a range of memory

On Tue, Jul 26, 2016 at 4:22 PM, Tamas K Lengyel wrote: > On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap > wrote: >> On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel >> wrote: >>> Currently mem-sharing can be

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: 26 July 2016 16:45 > To: Paul Durrant > Cc: Konrad Rzeszutek Wilk; zhigang.x.w...@oracle.com; Wei Liu; Stefano > Stabellini; Andrew Cooper; xen-devel@lists.xen.org; Anthony Perard > Subject: Re: [Xen-devel] live

[Xen-devel] [PATCH] xen/kconfig: unify messages of options moved from command line to kconfig

Change the message so that it mentions running from the top level directory and using '-C xen' in order to call the 'menuconfig' target inside of the xen directory (there's no top-level menuconfig target). Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

On Thu, May 26, Paul Durrant wrote: > It's likely to be a while before I could find some time for this; > rough guess would be a month... It depends how other stuff pans out. Any news, Paul? Did you have a chance to compose a fix? Olaf signature.asc Description: PGP signature

Re: [Xen-devel] [PATCH] xen: add static initialization of steal_clock op to xen_time_ops

On 26/07/16 13:15, Juergen Gross wrote: > pv_time_ops might be overwritten with xen_time_ops after the > steal_clock operation has been initialized already. To prevent calling > a now uninitialized function pointer add the steal_clock static > initialization to xen_time_ops. Applied to

Re: [Xen-devel] [PATCH v6] altp2m: Allow shared entries to be copied to altp2m views during lazycopy

On Tue, Jul 26, 2016 at 4:25 AM, George Dunlap wrote: > On Tue, Jul 26, 2016 at 10:35 AM, George Dunlap > wrote: >> On Mon, Jul 25, 2016 at 7:33 PM, Tamas K Lengyel >> wrote: >>> Move sharing locks above

Re: [Xen-devel] [PATCH v8] x86/mem-sharing: mem-sharing a range of memory

On Tue, Jul 26, 2016 at 3:12 AM, George Dunlap wrote: > On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel > wrote: >> Currently mem-sharing can be performed on a page-by-page basis from the >> control >> domain. However, this process is quite

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On 07/26/2016 12:01 AM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the xen-tip tree got a conflict in: > > arch/x86/xen/enlighten.c > > between commit: > > 4c9075835511 ("xen/x86: Move irq allocation from Xen smp_op.cpu_up()") > > from the tip tree and commit: > >

Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid generating inappropriate zero-length records

Wei Liu writes ("Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid generating inappropriate zero-length records"): > On Mon, Jul 25, 2016 at 06:15:37PM +0100, Ian Jackson wrote: > > Is the ultimate bug that we are tripping over here simply that the > > code calls malloc(0) and then bails if the libc

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

David Vrabel writes: > On 26/07/16 13:30, Vitaly Kuznetsov wrote: >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In >> particular, when we crash on a secondary vCPU we may want to do kdump >> and unlike plain kexec where we do migrate_to_reboot_cpu()

Re: [Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

On 26/07/16 13:30, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This

[Xen-devel] [PATCH linux v3 5/9] x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the shared_info page

shared_info page has space for 32 vcpu info slots for first 32 vCPUs but these are the first 32 vCPUs from Xen's perspective and we should map them accordingly with the newly introduced xen_vcpu_id mapping. Signed-off-by: Vitaly Kuznetsov --- Changes since v1: - Use

[Xen-devel] [PATCH linux v3 4/9] x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op

HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter while Xen's idea is expected. In some cases these ideas diverge so we need to do remapping. Convert all callers of HYPERVISOR_vcpu_op() to use xen_vcpu_nr(). Leave xen_fill_possible_map() and xen_filter_cpu_maps() intact as they're

[Xen-devel] [PATCH linux v3 2/9] x86/acpi: store ACPI ids from MADT for future usage

Currently we don't save ACPI ids (unlike LAPIC ids which go to x86_cpu_to_apicid) from MADT and we may need this information later. Particularly, ACPI ids is the only existent way for a PVHVM Xen guest to figure out Xen's idea of its vCPUs ids before these CPUs boot and in some cases these ids

[Xen-devel] [PATCH linux v3 9/9] xen/pvhvm: run xen_vcpu_setup() for the boot CPU

Historically we didn't call VCPUOP_register_vcpu_info for CPU0 for PVHVM guests (while we had it for PV and ARM guests). This is usually fine as we can use vcpu info in the sared_info page but when we try booting on a vCPU with Xen's vCPU id > 31 (e.g. when we try to kdump after crashing on this

[Xen-devel] [PATCH linux v3 7/9] xen/events: fifo: use xen_vcpu_id mapping

EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id mapping to convert it from Linux's id. Signed-off-by: Vitaly Kuznetsov --- Changes since v1: - Use xen_vcpu_nr() helper [David Vrabel] ---

[Xen-devel] [PATCH linux v3 8/9] xen/evtchn: use xen_vcpu_id mapping

Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id for CPU0. Signed-off-by: Vitaly Kuznetsov --- Changes since v1: - Use xen_vcpu_nr() helper [David Vrabel] --- drivers/xen/evtchn.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH linux v3 6/9] xen/events: use xen_vcpu_id mapping in events_base

EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id mapping to convert it from Linux's id. Signed-off-by: Vitaly Kuznetsov --- Changes since v1: - Use xen_vcpu_nr() helper [David

[Xen-devel] [PATCH linux v3 1/9] x86/xen: update cpuid.h from Xen-4.7

Update cpuid.h header from xen hypervisor tree to get XEN_HVM_CPUID_VCPU_ID_PRESENT definition. Signed-off-by: Vitaly Kuznetsov --- arch/x86/include/asm/xen/cpuid.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/xen/cpuid.h

[Xen-devel] [PATCH linux v3 0/9] xen: pvhvm: support bootup on secondary vCPUs

It may happen that Xen's and Linux's ideas of vCPU id diverge. In particular, when we crash on a secondary vCPU we may want to do kdump and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting on the vCPU which crashed. This doesn't work very well for PVHVM guests as we have a

[Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

It may happen that Xen's and Linux's ideas of vCPU id diverge. In particular, when we crash on a secondary vCPU we may want to do kdump and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting on the vCPU which crashed. This doesn't work very well for PVHVM guests as we have a

[Xen-devel] [libvirt test] 99696: tolerable FAIL - PUSHED

flight 99696 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/99696/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12

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

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

[Xen-devel] [PATCH] xen: add static initialization of steal_clock op to xen_time_ops

pv_time_ops might be overwritten with xen_time_ops after the steal_clock operation has been initialized already. To prevent calling a now uninitialized function pointer add the steal_clock static initialization to xen_time_ops. Signed-off-by: Juergen Gross ---

[Xen-devel] Xen Security Advisory 183 (CVE-2016-6259) - x86: Missing SMAP whitelisting in 32-bit exception / event delivery

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-6259 / XSA-183 version 5 x86: Missing SMAP whitelisting in 32-bit exception / event delivery UPDATES IN VERSION 5 Public release. ISSUE DESCRIPTION

[Xen-devel] Xen Security Advisory 182 (CVE-2016-6258) - x86: Privilege escalation in PV guests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-6258 / XSA-182 version 3 x86: Privilege escalation in PV guests UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION =

[Xen-devel] [xen-unstable test] 99685: regressions - FAIL

flight 99685 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/99685/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 debian-installfail REGR. vs. 97664

[Xen-devel] [xen-unstable-smoke test] 99707: tolerable all pass - PUSHED

flight 99707 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/99707/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

[Xen-devel] [qemu-mainline test] 99672: tolerable FAIL - PUSHED

flight 99672 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/99672/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 97740

Re: [Xen-devel] Xen 4.8 Development Update

On Tue, Jul 19, 2016 at 02:48:30PM +0100, Wei Liu wrote: > This email only tracks big items for xen.git tree. Please reply for items you > woulk like to see in 4.8 so that people have an idea what is going on and > prioritise accordingly. > > You're welcome to provide description and use cases of

Re: [Xen-devel] [PATCH v2 1/1] ratelimit: Implement rate limit for credit2 scheduler Rate limit assures that a vcpu will execute for a minimum amount of time before being put at the back of a queue or

On Mon, 2016-07-25 at 15:36 +0100, anshul makkar wrote: > On 22/07/16 11:36, Dario Faggioli wrote: > >  > > This version is an improvement, but it looks to me that you've > > missed a > > few of the review comments to v1. > > Sorry about that. !! > NP. It's indeed something quite important... but

Re: [Xen-devel] [PATCH v6] altp2m: Allow shared entries to be copied to altp2m views during lazycopy

On Tue, Jul 26, 2016 at 10:35 AM, George Dunlap wrote: > On Mon, Jul 25, 2016 at 7:33 PM, Tamas K Lengyel > wrote: >> Move sharing locks above altp2m to avoid locking order violation and crashing >> the hypervisor during unsharing

Re: [Xen-devel] [XTF PATCH v3] Correct the usage of $(DESTDIR) and $(PREFIX)

On 26/07/16 11:14, Ian Jackson wrote: > Andrew Cooper writes ("[XTF PATCH v3] Correct the usage of $(DESTDIR) and > $(PREFIX)"): >> The GNU coding standards expect $(DESTDIR) to be the root of everything >> installed, and for $(PREFIX) to then be added to the path. This is not how >> XTF

Re: [Xen-devel] [PATCH] xsm: don't require configuring tools to build xen xsm blob

Wei Liu writes ("[PATCH] xsm: don't require configuring tools to build xen xsm blob"): > Starting from 08cffe66 ("xsm: add a default policy to .init.data") we > can attach a xsm policy blob to hypervisor. To build that policy blob > now hypervisor build system needs to enter tools directory. > >

Re: [Xen-devel] [XTF PATCH v3] Correct the usage of $(DESTDIR) and $(PREFIX)

Andrew Cooper writes ("[XTF PATCH v3] Correct the usage of $(DESTDIR) and $(PREFIX)"): > The GNU coding standards expect $(DESTDIR) to be the root of everything > installed, and for $(PREFIX) to then be added to the path. This is not how > XTF previously behaved. > > XTF is not a typical

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

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

Re: [Xen-devel] [xen-unstable test] 97737: regressions - FAIL

On Tue, Jul 26, 2016 at 10:52:13AM +0100, Julien Grall wrote: > > > On 25/07/16 12:53, Wei Liu wrote: > >On Mon, Jul 25, 2016 at 12:34:53PM +0100, Julien Grall wrote: > >> > >> > >>On 25/07/16 12:11, Wei Liu wrote: > >>>Thanks for investigating. > >>> > >>>There are only two arm related changes

[Xen-devel] [distros-debian-snapshot test] 66811: trouble: blocked/broken/fail/pass

flight 66811 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66811/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 4 capture-logsbroken

Re: [Xen-devel] [PATCH] tools/libxc: Properly increment ApicIdCoreSize field on AMD

Wei Liu writes ("Re: [PATCH] tools/libxc: Properly increment ApicIdCoreSize field on AMD"): > On Mon, Jul 25, 2016 at 12:33:37PM +0100, Ian Jackson wrote: > > Wei Liu writes ("Re: [PATCH] tools/libxc: Properly increment ApicIdCoreSize > > field on AMD"): > > > Ian, this is a backport candidate

Re: [Xen-devel] [xen-unstable test] 97737: regressions - FAIL

On 25/07/16 12:53, Wei Liu wrote: On Mon, Jul 25, 2016 at 12:34:53PM +0100, Julien Grall wrote: On 25/07/16 12:11, Wei Liu wrote: Thanks for investigating. There are only two arm related changes in the range being tested: * a43cc8f - (origin/smoke) arm/traps: fix bug in

Re: [Xen-devel] [PATCH v2 2/3] xen: Have schedulers revise initial placement

On 26/07/16 10:30, Dario Faggioli wrote: > On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote: >> The generic domain creation logic in >> xen/common/domctl.c:default_vcpu0_location() attempts to try to do >> initial placement load-balancing by placing vcpu 0 on the least-busy >> non-primary

Re: [Xen-devel] [PATCH v6] altp2m: Allow shared entries to be copied to altp2m views during lazycopy

On Mon, Jul 25, 2016 at 7:33 PM, Tamas K Lengyel wrote: > Move sharing locks above altp2m to avoid locking order violation and crashing > the hypervisor during unsharing operations when altp2m is active. > > Applying mem_access settings or remapping gfns in altp2m

Re: [Xen-devel] [PATCH v2 1/3] xen: Some code motion to avoid having to do forward-declaration

On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote: > This is pure code motion; no functional change. > > Signed-off-by: George Dunlap > Reviewed-by: Meng Xu > Acked-by: Dario Faggioli > v2: > - Rebase on top of

Re: [Xen-devel] [PATCH v2 2/3] xen: Have schedulers revise initial placement

On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote: > The generic domain creation logic in > xen/common/domctl.c:default_vcpu0_location() attempts to try to do > initial placement load-balancing by placing vcpu 0 on the least-busy > non-primary hyperthread available.  Unfortunately, the logic

Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid generating inappropriate zero-length records

On Mon, Jul 25, 2016 at 06:15:37PM +0100, Ian Jackson wrote: > David Vrabel writes ("Re: [Xen-devel] [PATCH 3/4] tools/libxc: Avoid > generating inappropriate zero-length records"): > > On 21/07/16 18:17, Andrew Cooper wrote: > > > It was never intended for records such as these to be sent with

Re: [Xen-devel] [PATCH v2 3/3] xen: Remove buggy initial placement algorithm

On 25/07/16 16:28, George Dunlap wrote: > The initial placement algorithm sometimes picks cpus outside of the > mask it's given, does a lot of unnecessary bitmasking, does its own > separate load calculation, and completely ignores vcpu hard and soft > affinities. Just get rid of it and rely on

Re: [Xen-devel] [PATCH 2/3] xen: Have schedulers revise initial placement

On Mon, 2016-07-25 at 12:17 +0100, George Dunlap wrote: > On 18/07/16 11:28, Dario Faggioli wrote: > > > > On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote: > > >  > > > Signed-off-by: George Dunlap > > > --- > > > CC: Dario Faggioli >

[Xen-devel] [PATCH v6 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

From: Fu Wei delete: xen_linux, xen_initrd, xen_xsm add: xen_module This update bases on commit 0edd750e50698854068358ea53528100a9192902 Author: Vladimir Serbinenko Date: Fri Jan 22 10:18:47 2016 +0100 xen_boot: Remove obsolete

[Xen-devel] [PATCH v6 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support

From: Fu Wei This patch adds the support of xen_boot command: xen_hypervisor xen_module Also add a new "feature_xen_boot" to indicate this grub support xen_boot command. Signed-off-by: Fu Wei --- grub-core/normal/main.c | 2 +-

Re: [Xen-devel] [PATCH v2 3/3] xen: Remove buggy initial placement algorithm

On Mon, 2016-07-25 at 16:28 +0100, George Dunlap wrote: > The initial placement algorithm sometimes picks cpus outside of the > mask it's given, does a lot of unnecessary bitmasking, does its own > separate load calculation, and completely ignores vcpu hard and soft > affinities.  Just get rid of

[Xen-devel] [PATCH v6 1/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386

From: Fu Wei Signed-off-by: Fu Wei --- grub-core/loader/i386/xen.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c index c4d9689..15b0727 100644 --- a/grub-core/loader/i386/xen.c +++

[Xen-devel] [PATCH v6 2/4] arm64: add "--nounzip" option support in xen_module command

From: Fu Wei This patch adds "--nounzip" option support in order to be compatible with the module command of i386, then we can simplify grub-mkconfig support code. Signed-off-by: Fu Wei --- grub-core/loader/arm64/xen_boot.c | 17 + 1 file

[Xen-devel] [PATCH v6 0/4] arm64, xen: add xen_boot support into grup-mkconfig

From: Fu Wei This patchset add xen_boot support into grup-mkconfig for generating xen boot entrances automatically Also update the docs/grub.texi for new xen_boot commands. This patchset has been tested on Foudation model with a bug fix:

Re: [Xen-devel] [PATCH v8] x86/mem-sharing: mem-sharing a range of memory

On Wed, Jul 20, 2016 at 7:01 PM, Tamas K Lengyel wrote: > Currently mem-sharing can be performed on a page-by-page basis from the > control > domain. However, this process is quite wasteful when a range of pages have to > be deduplicated. > > This patch introduces a

Re: [Xen-devel] [XTF PATCH v3] Correct the usage of $(DESTDIR) and $(PREFIX)

On Mon, Jul 25, 2016 at 05:23:18PM +0100, Andrew Cooper wrote: > The GNU coding standards expect $(DESTDIR) to be the root of everything > installed, and for $(PREFIX) to then be added to the path. This is not how > XTF previously behaved. > > XTF is not a typical package, and doesn't meet the

Re: [Xen-devel] [PATCH v2 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On 07/26/2016 04:44 PM, Roger Pau Monné wrote: > On Tue, Jul 26, 2016 at 01:19:37PM +0800, Bob Liu wrote: >> The current VBD layer reserves buffer space for each attached device based on >> three statically configured settings which are read at boot time. >> * max_indirect_segs: Maximum amount

Re: [Xen-devel] [PATCH XTF 3/3] xtf-runner: regularise runner exit code

on Mon, Jul 25, 2016 at 06:05:21PM +0100, Ian Jackson wrote: > Andrew Cooper writes ("Re: [PATCH XTF 3/3] xtf-runner: regularise runner exit > code"): > > On 25/07/16 12:25, Ian Jackson wrote: > > > In particular, Error might mask a failure. > > > > Indeed it could. Either should cause a prompt

Re: [Xen-devel] [PATCH v2 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On Tue, Jul 26, 2016 at 01:19:37PM +0800, Bob Liu wrote: > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount of segments. > * max_ring_page_order: Maximum order

Re: [Xen-devel] [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64

Hi all On 22 February 2016 at 17:29, Fu Wei wrote: > Hi Julien, > > On 20 February 2016 at 00:28, Julien Grall wrote: >> Xen is currently crashing because of malformed compatible property for >> the boot module. This is because the property string is

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

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

Re: [Xen-devel] xenbits and https redirect (was Re: [xen-unstable-smoke test] 99610: regressions - FAIL)

On Mon, Jul 25, 2016 at 4:24 PM, Ian Jackson wrote: > osstest service owner writes ("[xen-unstable-smoke test] 99610: regressions - > FAIL"): >> flight 99610 xen-unstable-smoke real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/99610/ >> >> Regressions :-(

Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs

Stefano Stabellini writes: > On Mon, 25 Jul 2016, Vitaly Kuznetsov wrote: >> >> While we're not obliged to have the same type for xen_vcpu_id on all >> arches I see no point in diverging without a reason. I can do v3 making >> the mapping uint32 > > I agree that making

Re: [Xen-devel] [PATCH v5 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support

Hi Julien, On 12 July 2016 at 18:21, Julien Grall wrote: > Hi Fu Wei, > > > On 06/07/16 18:53, fu@linaro.org wrote: >> >> From: Fu Wei >> >> This patch adds the support of xen_boot command: >> xen_hypervisor >> xen_module >> >> Also add a