Re: [Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

On Mon, Dec 05, 2016 at 01:32:43PM -0800, Andy Lutomirski wrote: > Aside from being excessively slow, CPUID is problematic: Linux runs > on a handful of CPUs that don't have CPUID. Use IRET-to-self > instead. IRET-to-self works everywhere, so it makes testing easy. > > For reference, On my

Re: [Xen-devel] [PATCH 1/2] xen/x86: return partial memory map in case of not enough space

On 05/12/16 18:17, Jan Beulich wrote: On 05.12.16 at 17:34, wrote: >> For XENMEM_machine_memory_map the hypervisor returns EINVAL if the >> caller's buffer can't hold all entries. >> >> This is a problem as the caller has normally a static buffer defined >> and when he is

[Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm testid xen-boot Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Re: [Xen-devel] Please Welcome Our New Release Manager

On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote: > On Mon, 5 Dec 2016, Wei Liu wrote: > > Dear community members, > > > > I'm pleased to announce that Julien Grall will be > > the Release Manager for the next Xen release. > > > > The appointment was

[Xen-devel] [PATCH] tools/xenstore: avoid unterminated string in xs_directory_part()

Commit d4016288ab1f ("xenstore: support XS_DIRECTORY_PART in libxenstore") introduced a theoretical bug: the generation count of the read node is transferred via strncpy without forcing a NUL byte at the end. Correct this. Signed-off-by: Juergen Gross --- tools/xenstore/xs.c |

Re: [Xen-devel] [PATCH v4 00/12] xenstore: support reading directory with many children

On 05/12/16 19:19, Andrew Cooper wrote: > On 05/12/16 12:05, Wei Liu wrote: >> On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote: >> [...] >>> Juergen Gross (12): >>> xenstore: modify add_change_node() parameter types >>> xenstore: call add_change_node() directly when writing node

[Xen-devel] [xen-4.8-testing baseline test] 102940: tolerable FAIL

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 102940 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102940/ Failures :-/

Re: [Xen-devel] [PATCH 5/8] x86/hvm: Don't raise #GP behind the emulators back for MSR accesses

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, December 05, 2016 6:09 PM > > The current hvm_msr_{read,write}_intercept() infrastructure calls > hvm_inject_hw_exception() directly to latch a fault, and returns > X86EMUL_EXCEPTION to its caller. > > This behaviour is

Re: [Xen-devel] [PATCH v2 4/4] x86/hvm: Move hvm_hypervisor_cpuid_leaf() handling into cpuid_hypervisor_leaves()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, December 06, 2016 2:25 AM > > This reduces the net complexity of CPUID handling by having all adjustments in > at the same place. Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf() > infrastructure. > >

Re: [Xen-devel] [PATCH v2 3/4] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Tuesday, December 06, 2016 2:25 AM > > This reduces the net complexity of CPUID handling by having all adjustments in remove 'in' > at the same place. Remove the now-unused hvm_funcs.cpuid_intercept > infrastructure. > > The

Re: [Xen-devel] [PATCH] xen-scsifront: Add a missing call to kfree

On 05/12/16 21:53, Dan Carpenter wrote: > On Mon, Nov 21, 2016 at 07:01:36AM +0100, Juergen Gross wrote: >> On 19/11/16 19:22, Quentin Lambert wrote: >>> Most error branches following the call to kmalloc contain >>> a call to kfree. This patch add these calls where they are >>> missing. >>> >>>

Re: [Xen-devel] mpt3sas bug with Debian jessie kernel only under Xen - "swiotlb buffer is full"

Hi Andrew, On Sun, Dec 04, 2016 at 03:59:20PM +, Andrew Cooper wrote: > On 04/12/16 08:32, Andy Smith wrote: > > Under the Debian jessie amd64 kernel (linux-image-3.16.0-4-amd64 > > 3.16.36-1+deb8u2) running under Xen, I cannot put the system's > > storage under heavy load without receiving a

[Xen-devel] [linux-4.1 test] 102929: regressions - trouble: broken/fail/pass

flight 102929 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/102929/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-rtds broken test-armhf-armhf-xl-vhd

[Xen-devel] [DOC v2] Xen transport for 9pfs

Changes in v2: - fix copy/paste error - rename ring-ref- to ring-ref - fix memory barriers - add "verify prod/cons against local copy" - add a paragraph on high level design - add a note on the maximum possible max-ring-page-order value - add mechanisms to avoid unnecessary evtchn notifications

[Xen-devel] [qemu-upstream-4.8-testing baseline test] 102941: tolerable FAIL

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 102941 qemu-upstream-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102941/

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

On 05/12/2016 19:17, Stefano Stabellini wrote: > On Mon, 5 Dec 2016, Andrew Cooper wrote: >> None of these barriers serve any purpose, as they are not synchronising with >> any anything on remote CPUs. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich

Re: [Xen-devel] Please Welcome Our New Release Manager

On 05/12/2016 20:41, Konrad Rzeszutek Wilk wrote: > On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote: >> On Mon, 5 Dec 2016, Wei Liu wrote: >>> Dear community members, >>> >>> I'm pleased to announce that Julien Grall will be >>> the Release Manager for the

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

flight 102920 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/102920/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675

[Xen-devel] [PATCH v11 06/13] efi: create new early memory allocator

There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory

[Xen-devel] [PATCH v11 13/13] x86: add multiboot2 protocol support for relocatable images

Add multiboot2 protocol support for relocatable images. Only GRUB2 with "multiboot2: Add support for relocatable images" patch understands that feature. Older multiboot protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v11 11/13] x86: make Xen early boot code relocatable

Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2

[Xen-devel] [PATCH v11 10/13] x86/setup: use XEN_IMG_OFFSET instead of...

..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index

[Xen-devel] [PATCH v11 09/13] x86: change default load address from 1 MiB to 2 MiB

Subsequent patches introducing relocatable early boot code play with page tables using 2 MiB huge pages. If load address is not aligned at 2 MiB then code touching such page tables must have special cases for start and end of Xen image memory region. So, let's make life easier and move default

[Xen-devel] [PATCH v11 12/13] x86/boot: rename sym_phys() to sym_offs()

This way macro name better describes its function. Currently it is used to calculate symbol offset in relation to the beginning of Xen image mapping. However, value returned by sym_offs() for a given symbol is not always equal its physical address. There is no functional change. Suggested-by:

[Xen-devel] [PATCH v11 08/13] x86/boot: implement early command line parser in C

Current early command line parser implementation in assembler is very difficult to change to relocatable stuff using segment registers. This requires a lot of changes in very weird and fragile code. So, reimplement this functionality in C. This way code will be relocatable out of the box (without

[Xen-devel] [PATCH v11 03/13] x86: allow EFI reboot method neither on EFI platforms...

..nor EFI platforms with runtime services enabled. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- v6 - suggestions/fixes: - move this commit behind "efi: create efi_enabled()" commit

[Xen-devel] [PATCH v11 01/13] x86: add multiboot2 protocol support

Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v10 - suggestions/fixes: - replace ljmpl with lretq (suggested by Andrew Cooper), - introduce efi_platform to

[Xen-devel] [PATCH v11 02/13] efi: create efi_enabled()

First of all we need to differentiate between legacy BIOS and EFI platforms during runtime, not during build, because one image will have legacy and EFI code and can be executed on both platforms. Additionally, we need more fine grained knowledge about EFI environment and check for EFI platform

[Xen-devel] [PATCH v11 04/13] x86: properly calculate xen ELF end of image address

This patch is prereq for "efi: build xen.gz with EFI code" patch which adds, among others, xen/arch/x86/efi/relocs-dummy.S to xen.gz output. Below there is a description why it is needed. Currently xen ELF end of image address is calculated using first line from "nm -nr xen/xen-syms" output.

[Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

Hi, I am sending eleventh version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS platforms)

[Xen-devel] [PATCH v11 05/13] efi: build xen.gz with EFI code

Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement of both boot protocols. Currently, PE file

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

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

[Xen-devel] [PATCH v3 1/4] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

We support various non-Intel CPUs that don't have the CPUID instruction, so the M486 test was wrong. For now, fix it with a big hammer: handle missing CPUID on all 32-bit CPUs. Reported-by: One Thousand Gnomes Signed-off-by: Andy Lutomirski ---

[Xen-devel] [PATCH v3 0/4] CPUID-less CPU/sync_core fixes and improvements

*** PATCHES 1 and 2 MAY BE 4.9 MATERIAL *** Alan Cox pointed out that the 486 isn't the only supported CPU that doesn't have CPUID. Let's clean up the mess and make everything faster while we're at it. Patch 1 is intended to be an easy fix: it makes sync_core() work without CPUID on all 32-bit

[Xen-devel] [PATCH v3 3/4] x86/microcode/intel: Replace sync_core() with native_cpuid()

The Intel microcode driver is using sync_core() to mean "do CPUID with EAX=1". I want to rework sync_core(), but first the Intel microcode driver needs to stop depending on its current behavior. Reported-by: Henrique de Moraes Holschuh Acked-by: Borislav Petkov

[Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

Aside from being excessively slow, CPUID is problematic: Linux runs on a handful of CPUs that don't have CPUID. Use IRET-to-self instead. IRET-to-self works everywhere, so it makes testing easy. For reference, On my laptop, IRET-to-self is ~110ns, CPUID(eax=1, ecx=0) is ~83ns on native and very

[Xen-devel] [PATCH v3 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"

This reverts commit ed68d7e9b9cfb64f3045ffbcb108df03c09a0f98. The patch wasn't quite correct -- there are non-Intel (and hence non-486) CPUs that we support that don't have CPUID. Since we no longer require CPUID for sync_core(), just revert the patch. I think the relevant CPUs are Geode and

Re: [Xen-devel] [PATCH v2 3/4] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

On 12/05/2016 01:24 PM, Andrew Cooper wrote: > This reduces the net complexity of CPUID handling by having all adjustments in > at the same place. Remove the now-unused hvm_funcs.cpuid_intercept > infrastructure. > > The SYSCALL feature hiding is tweaked when moved. In principle, an >

Re: [Xen-devel] [PATCH v2 2/4] x86/vpmu: Remove core2_no_vpmu_ops

On 12/05/2016 01:24 PM, Andrew Cooper wrote: > core2_no_vpmu_ops exists solely to work around the default-leaking of > CPUID/MSR > values in Xen. > > With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last > remaining hook. Since core2_no_vpmu_ops's introduction in c/s

Re: [Xen-devel] [PATCH v2 1/4] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

On 12/05/2016 01:24 PM, Andrew Cooper wrote: > @@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, > unsigned int *ebx, > if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) ) > *edx &= ~cpufeat_mask(X86_FEATURE_PSE36); > } > + >

Re: [Xen-devel] [PATCH] xen-scsifront: Add a missing call to kfree

On Mon, Nov 21, 2016 at 07:01:36AM +0100, Juergen Gross wrote: > On 19/11/16 19:22, Quentin Lambert wrote: > > Most error branches following the call to kmalloc contain > > a call to kfree. This patch add these calls where they are > > missing. > > > > This issue was found with Hector. > > > >

[Xen-devel] Test Xen 4.8 RC8 stable 05.12.16

* Hardware: Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz Sandisk SSD 1T 32G Ram Linux xen 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux * Software: Debian Stretch/testing is dom0 * Guest operating systems: Guests Ubuntu 14.04 LTS Debian Stretch/Sid Ubuntu 16.10 yakity

Re: [Xen-devel] Please Welcome Our New Release Manager

On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote: > On Mon, 5 Dec 2016, Wei Liu wrote: > > Dear community members, > > > > I'm pleased to announce that Julien Grall will be > > the Release Manager for the next Xen release. > > > > The appointment was

Re: [Xen-devel] Please Welcome Our New Release Manager

On Mon, 5 Dec 2016, Wei Liu wrote: > Dear community members, > > I'm pleased to announce that Julien Grall will be > the Release Manager for the next Xen release. > > The appointment was voted by the Committers and the vote passed. > > Julien has done excellent jobs in

Re: [Xen-devel] [PATCH] xen/arm: traps: Emulate ICC_SRE_EL1 as RAZ/WI

On Mon, 5 Dec 2016, Julien Grall wrote: > Recent Linux kernel (4.4 and onwards [1]) is checking whether it is possible > to enable sysreg access (ICC_SRE_EL1.SRE) when the ID register > (ID_AA64PRF0_EL1.GIC) is reporting the presence of the sysreg interface. > > When the guest has been configured

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

On Mon, 5 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 01/12/16 21:33, Stefano Stabellini wrote: > > On Thu, 1 Dec 2016, Julien Grall wrote: > > > On 01/12/16 02:07, Stefano Stabellini wrote: > > > > On Fri, 25 Nov 2016, Julien Grall wrote: > > > > > Hi Stefano, > > > > > > Hi, > > > > >

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

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

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

On Mon, 5 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 03/12/16 00:46, Stefano Stabellini wrote: > > On Fri, 2 Dec 2016, Andre Przywara wrote: > > > > When we receive the maintenance interrupt and we clear the LR of the > > > > vLPI, Xen should re-enable the pLPI. > > > > Given that the

[Xen-devel] [PATCH v2] AMD IOMMU: Support IOAPIC IDs larger than 128

Currently, the driver uses the APIC ID to index into the ioapic_sbdf array. The current MAX_IO_APICS is 128, which causes the driver initialization to fail on the system with IOAPIC ID >= 128. Instead, this patch adds APIC ID in the struct ioapic_sbdf, which is used to match the entry when

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

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

Re: [Xen-devel] Possible improvement to Xen Security Response Process

On Mon, 5 Dec 2016, Jan Beulich wrote: > >>> On 05.12.16 at 15:17, wrote: > > From a security purist point of view, any delay in publication could > > increase the possibility of vulnerabilities being exploited in the > > wild. However, given the significant frequency

Re: [Xen-devel] [PATCH 2/2] Travis-ci: specify KCONFIG_ALLCONFIG for randconfig

On 12/5/16 10:45 AM, Wei Liu wrote: > The file provided contains symbols that must be set to certain values. > This then prevents random build breakage in travis due to > known-incompatible symbol selections. > > Signed-off-by: Wei Liu > --- > Cc: Doug Goldstein

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

On Mon, 5 Dec 2016, Jan Beulich wrote: > >>> On 05.12.16 at 14:59, wrote: > > On 05/12/16 13:50, Jan Beulich wrote: > > On 05.12.16 at 14:43, wrote: > >>> On 05/12/16 12:28, Jan Beulich wrote: > >>> On 05.12.16 at 12:25,

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

On Mon, 5 Dec 2016, Andrew Cooper wrote: > None of these barriers serve any purpose, as they are not synchronising with > any anything on remote CPUs. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Stefano Stabellini

Re: [Xen-devel] [PATCH 1/4] xen/common: Replace incorrect mandatory barriers with SMP barriers

On Mon, 5 Dec 2016, Andrew Cooper wrote: > Mandatory barriers are only for use with reduced-cacheability MMIO mappings. > > All of these uses are just to deal with shared memory between multiple > processors, so use the smp_*() which are the correct barriers for the purpose. > > Signed-off-by:

Re: [Xen-devel] [PATCH v1] arm/irq: Reorder check when the IRQ is already used by someone

On Mon, 5 Dec 2016, Julien Grall wrote: > Hi Oleksandr, > > On 02/12/16 16:38, Oleksandr Tyshchenko wrote: > > Call irq_get_domain for the IRQ we are interested in > > only after making sure that it is the guest IRQ to avoid > > ASSERT(test_bit(_IRQ_GUEST, >status)) triggering. > > > >

[Xen-devel] [xen-4.4-testing test] 102914: FAIL

flight 102914 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102914/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt3 host-install(3) broken in 102751 REGR. vs.

[Xen-devel] [PATCH v2 1/4] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

This reduces the net complexity of CPUID handling by having all adjustments in at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure. This involves introducing a vpmu_enabled() predicate, and making the Intel specific VPMU_CPU_HAS_* constants public. Signed-off-by: Andrew

[Xen-devel] [PATCH v2 2/4] x86/vpmu: Remove core2_no_vpmu_ops

core2_no_vpmu_ops exists solely to work around the default-leaking of CPUID/MSR values in Xen. With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last remaining hook. Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu intel: Add cpuid handling when vpmu

[Xen-devel] [PATCH v2 3/4] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

This reduces the net complexity of CPUID handling by having all adjustments in at the same place. Remove the now-unused hvm_funcs.cpuid_intercept infrastructure. The SYSCALL feature hiding is tweaked when moved. In principle, an administrator can choose to explicitly hide the SYSCALL feature

[Xen-devel] [PATCH v2 0/4] Introductory cleanup for CPUID phase 2 work

This is some cleanup intended to ease the development of further development work. There is no practical change from a guests point of view. Andrew Cooper (4): x86/vpmu: Move vpmu_do_cpuid() handling into {pv,hvm}_cpuid() x86/vpmu: Remove core2_no_vpmu_ops x86/hvm: Move

[Xen-devel] [PATCH v2 4/4] x86/hvm: Move hvm_hypervisor_cpuid_leaf() handling into cpuid_hypervisor_leaves()

This reduces the net complexity of CPUID handling by having all adjustments in at the same place. Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf() infrastructure. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima

Re: [Xen-devel] [PATCH v4 00/12] xenstore: support reading directory with many children

On 05/12/16 12:05, Wei Liu wrote: > On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote: > [...] >> Juergen Gross (12): >> xenstore: modify add_change_node() parameter types >> xenstore: call add_change_node() directly when writing node >> xenstore: use common tdb record header in

[Xen-devel] [libvirt test] 102921: regressions - FAIL

flight 102921 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/102921/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 102830

Re: [Xen-devel] [PATCH 1/2] Kconfig: introduce allrandom.config

On 12/5/16 10:45 AM, Wei Liu wrote: > This would be used to force selection of certain items in randconfig. > > We need this to force gcov format to be autodetected in randconfig > target, which would avoid generating known-incompatible combinations. > > Signed-off-by: Wei Liu

[Xen-devel] [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

It's really not necessary to limit E820_X_MAX to 128 in the non-EFI case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that E820_X_MAX is always at least slightly larger than E820MAX. The real motivation behind this is actually to prevent some issues in the Xen kernel, where the

[Xen-devel] [RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

This is the third pass at my patchset to fix up our problems with XENMEM_machine_memory_map on large systems. The only changes on this pass were to flesh out the comment above the E820_X_MAX definition, and to add Juergen's Reviewed-by to the second patch. Let me know if anyone has any

[Xen-devel] [PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On systems with sufficiently large e820 tables, and several IOAPICs, it is possible for the XENMEM_machine_memory_map callback (and its counterpart, XENMEM_memory_map) to attempt to return an e820 table with more than 128 entries. This callback adds entries to the BIOS-provided e820 table to

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

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

[Xen-devel] [PATCH] xen/arm: traps: Emulate ICC_SRE_EL1 as RAZ/WI

Recent Linux kernel (4.4 and onwards [1]) is checking whether it is possible to enable sysreg access (ICC_SRE_EL1.SRE) when the ID register (ID_AA64PRF0_EL1.GIC) is reporting the presence of the sysreg interface. When the guest has been configured to use GICv2, the hypervisor will disable sysreg

Re: [Xen-devel] [PATCH 1/2] xen/x86: return partial memory map in case of not enough space

>>> On 05.12.16 at 17:34, wrote: > For XENMEM_machine_memory_map the hypervisor returns EINVAL if the > caller's buffer can't hold all entries. > > This is a problem as the caller has normally a static buffer defined > and when he is doing the call no dynamic memory allocation

Re: [Xen-devel] [PATCH 5/8] x86/hvm: Don't raise #GP behind the emulators back for MSR accesses

>>> On 05.12.16 at 17:29, wrote: > On 05/12/16 12:10, Jan Beulich wrote: > On 05.12.16 at 11:09, wrote: >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -509,7 +509,11 @@ void hvm_do_resume(struct vcpu *v) >>>

Re: [Xen-devel] [PATCH 0/2] xen: modify dom0 interface for obtaining memory map

On 05/12/16 16:43, Juergen Gross wrote: > On 05/12/16 17:39, Andrew Cooper wrote: >> On 05/12/16 16:34, Juergen Gross wrote: >>> Today's interface to get the machine memory map in dom0 requires to >>> know in advance how large the final map will be. There is however no >>> way to either get only a

Re: [Xen-devel] [PATCH 2/2] Travis-ci: specify KCONFIG_ALLCONFIG for randconfig

On 05/12/16 16:45, Wei Liu wrote: > The file provided contains symbols that must be set to certain values. > This then prevents random build breakage in travis due to > known-incompatible symbol selections. > > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH 1/2] Kconfig: introduce allrandom.config

On 05/12/16 16:45, Wei Liu wrote: > This would be used to force selection of certain items in randconfig. > > We need this to force gcov format to be autodetected in randconfig > target, which would avoid generating known-incompatible combinations. > > Signed-off-by: Wei Liu

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

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

[Xen-devel] [PATCH 0/2] Fix randconfig build in travis-ci

Wei Liu (2): Kconfig: introduce allrandom.config Travis-ci: specify KCONFIG_ALLCONFIG for randconfig scripts/travis-build | 2 +- xen/tools/kconfig/allrandom.config | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 xen/tools/kconfig/allrandom.config --

[Xen-devel] [PATCH 1/2] Kconfig: introduce allrandom.config

This would be used to force selection of certain items in randconfig. We need this to force gcov format to be autodetected in randconfig target, which would avoid generating known-incompatible combinations. Signed-off-by: Wei Liu --- Cc: Doug Goldstein

[Xen-devel] [PATCH 2/2] Travis-ci: specify KCONFIG_ALLCONFIG for randconfig

The file provided contains symbols that must be set to certain values. This then prevents random build breakage in travis due to known-incompatible symbol selections. Signed-off-by: Wei Liu --- Cc: Doug Goldstein --- scripts/travis-build | 2 +- 1 file

Re: [Xen-devel] [PATCH 0/2] xen: modify dom0 interface for obtaining memory map

On 05/12/16 17:39, Andrew Cooper wrote: > On 05/12/16 16:34, Juergen Gross wrote: >> Today's interface to get the machine memory map in dom0 requires to >> know in advance how large the final map will be. There is however no >> way to either get only a part of the memory map or to ask the >>

Re: [Xen-devel] [PATCH 0/2] xen: modify dom0 interface for obtaining memory map

On 05/12/16 16:34, Juergen Gross wrote: > Today's interface to get the machine memory map in dom0 requires to > know in advance how large the final map will be. There is however no > way to either get only a part of the memory map or to ask the > hypervisor about its size. > > This patch set

Re: [Xen-devel] [PATCH] stubdom: correct dependency for ioemu linkfarm

On 08/11/16 07:29, Juergen Gross wrote: > The dependency for setting up the links for ioemu is wrong: it is > depending on tools/qemu-xen-traditional-dir which is being modified by > each "make tools" call. This leads to rebuilds of several stubdom > libraries for each call of "make stubdom" as

[Xen-devel] [PATCH 2/2] xen/x86: add a way to obtain the needed number of memory map entries

Today there is no way for a domain to obtain the number of entries of the machine memory map returned by XENMEM_machine_memory_map hypercall. Modify the interface to return just the needed number of map entries in case the buffer was specified as NULL. Signed-off-by: Juergen Gross

[Xen-devel] [PATCH 0/2] xen: modify dom0 interface for obtaining memory map

Today's interface to get the machine memory map in dom0 requires to know in advance how large the final map will be. There is however no way to either get only a part of the memory map or to ask the hypervisor about its size. This patch set enhances the XENMEM_machine_memory_map hypercall to

[Xen-devel] [PATCH 1/2] xen/x86: return partial memory map in case of not enough space

For XENMEM_machine_memory_map the hypervisor returns EINVAL if the caller's buffer can't hold all entries. This is a problem as the caller has normally a static buffer defined and when he is doing the call no dynamic memory allocation is possible as nothing is yet known about the system's memory

Re: [Xen-devel] [PATCH 5/8] x86/hvm: Don't raise #GP behind the emulators back for MSR accesses

On 05/12/16 12:10, Jan Beulich wrote: On 05.12.16 at 11:09, wrote: >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -509,7 +509,11 @@ void hvm_do_resume(struct vcpu *v) >> >> if ( w->do_write.msr ) >> { >> -

[Xen-devel] [xen-4.5-testing test] 102905: regressions - FAIL

flight 102905 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/102905/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-4 52 leak-check/check fail REGR. vs. 102721

Re: [Xen-devel] [PATCH] xen: convert lto to Kconfig option

On Mon, Dec 05, 2016 at 08:58:20AM -0700, Jan Beulich wrote: > >>> On 05.12.16 at 16:27, wrote: > > On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote: > >> On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote: > >> > >>> On 05.12.16 at 15:39,

Re: [Xen-devel] [PATCH] xen: convert lto to Kconfig option

>>> On 05.12.16 at 16:27, wrote: > On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote: >> On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote: >> > >>> On 05.12.16 at 15:39, wrote: >> > > Introduce CONFIG_LTO in Kconfig. Since this is the

Re: [Xen-devel] [PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready

On 05/12/16 16:32, Boris Ostrovsky wrote: > On 12/02/2016 01:15 AM, Juergen Gross wrote: >> >> -static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info >> *info) >> +static int scsifront_do_request(struct vscsifrnt_info *info, >> +struct

Re: [Xen-devel] [PATCH v3 1/5] tools/libacpi: add _FADT_ to the FADT boot flags definitions

On Mon, Dec 05, 2016 at 03:04:53PM +, Roger Pau Monne wrote: > Signed-off-by: Roger Pau Monné > --- Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready

On 12/02/2016 01:15 AM, Juergen Gross wrote: > > -static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info *info) > +static int scsifront_do_request(struct vscsifrnt_info *info, > + struct vscsifrnt_shadow *shadow) > { > struct vscsiif_front_ring

Re: [Xen-devel] [PATCH] xen: convert lto to Kconfig option

On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote: > On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote: > > >>> On 05.12.16 at 15:39, wrote: > > > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be > > > converted to Kconfig, delete the

Re: [Xen-devel] [PATCH] xen: convert lto to Kconfig option

On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote: > >>> On 05.12.16 at 15:39, wrote: > > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be > > converted to Kconfig, delete the preceding comment in Rules.mk as well. > > > > Make it depend on

[Xen-devel] [PATCH v3 3/5] tools/libacpi: don't announce a 8042 controller in the FADT for PVHv2 guests

There's no such controler available for PVHv2 guests. Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson Cc:

[Xen-devel] [PATCH v3 2/5] tools/libacpi: set FADT boot flag to notify lack of VGA for PVHv2 guests

PVHv2 guests don't have any VGA card, and as so it must be notified in the FADT. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich Reviewed-by: Andrew Cooper --- Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [PATCH v3 1/5] tools/libacpi: add _FADT_ to the FADT boot flags definitions

Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson Cc: Wei Liu Cc: boris.ostrov...@oracle.com Cc: konrad.w...@oracle.com --- Changes since v2:

Re: [Xen-devel] [PATCH v3 1/5] tools/libacpi: add _FADT_ to the FADT boot flags definitions

On 05/12/16 15:04, Roger Pau Monne wrote: > Signed-off-by: Roger Pau Monné Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 4/5] tools/libacpi: update FADT layout to support version 5

Update the structure of the FADT table to version 5, and use that version for PVHv2 guests. Note that HVM guests will continue to use FADT 4. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson

  1   2   >