[Xen-devel] [ovmf test] 104186: trouble: blocked/broken

flight 104186 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104186/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm3 host-install(3)broken REGR. vs. 104163

[Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

Hi all, I have a working IGD passthrough setup running for 4 years on XEN 4.3.2. And it no longer works after I upgraded to XEN4.8.0 yesterday. Really need suggestions this time. My previous setup was built upon some local fixes in qemu-xen-traditional (for vendor specific pci cap). With the same

Re: [Xen-devel] [PATCH] tools/misc: add AVX512 vpopcntdq in xen-cpuid.c

CC Andrew and Jan On Mon, Jan 16, 2017 at 04:05:03PM +0800, He Chen wrote: > Add AVX512 vpopcntdq information in xen-cpuid.c > > Signed-off-by: He Chen > --- > tools/misc/xen-cpuid.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git

[Xen-devel] [PATCH] tools/misc: add AVX512 vpopcntdq in xen-cpuid.c

Add AVX512 vpopcntdq information in xen-cpuid.c Signed-off-by: He Chen --- tools/misc/xen-cpuid.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c index 5d66e94..106be0f 100644 ---

Re: [Xen-devel] [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs

On 13/01/17 19:37, Stefano Stabellini wrote: > On Thu, 12 Jan 2017, Andre Przywara wrote: Hi Stefano, ... +list_for_each_entry(lpi_irq, >arch.vgic.pending_lpi_list, entry) +{ +if ( lpi_irq->pirq.irq == lpi ) +return _irq->pirq; + +

Re: [Xen-devel] [PATCH] tools/misc: add AVX512 vpopcntdq in xen-cpuid.c

On 16/01/17 09:41, Wei Liu wrote: > CC Andrew and Jan > > On Mon, Jan 16, 2017 at 04:05:03PM +0800, He Chen wrote: >> Add AVX512 vpopcntdq information in xen-cpuid.c >> >> Signed-off-by: He Chen Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH 4/8] x86emul: support BMI2 insns

>>> On 13.01.17 at 19:20, wrote: > On 13/01/17 15:32, Jan Beulich wrote: >> Note that the adjustment to the mode_64bit() definition is so that we >> can avoid "#ifdef __x86_64__" around the 64-bit asm() portions. An >> alternative would be single asm()s with a

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

On 16/01/17 11:19, Jan Beulich wrote: On 13.01.17 at 18:40, wrote: >> On 13/01/17 15:31, Jan Beulich wrote: >>> @@ -5866,6 +5879,67 @@ x86_emulate( >>> break; >>> #endif >>> >>> +case X86EMUL_OPC_VEX(0x0f38, 0xf2):/* andn r/m,r,r */ >>> +

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

>>> On 16.01.17 at 06:25, wrote: > One thing noted though. The original patch from Quan is actually orthogonal > to this ASSERT. Regardless of whether intack.vector is larger or smaller > than pt_vector, we always require the trick as long as pt_vector is not the > one being

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

>>> On 13.01.17 at 20:21, wrote: > Doug v1 - fix incorrect assembly (identified by Andrew Cooper) > - fix issue where the trampoline size was left as 0 and the > way the memory is allocated for the trampolines we would go to > the end of an available

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

>>> On 14.01.17 at 03:52, wrote: > On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote: >> In a native situation, SMAP raises #PF if hardware tries to follow a >> user pointer outside of an area whitelisted by the kernel. (The >> copy_*_guest path

[Xen-devel] [distros-debian-sid test] 68374: trouble: blocked/broken

flight 68374 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68374/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken REGR.

[Xen-devel] [PATCH v2 0/2] XEN SWIOTLB for ARM dma operations extension

From: Andrii Anisov Some drivers need additional dma ops to be provided by xen swiotlb. Because common operations implementation came from x86 world and does not suite ARM needs we have to provide needed XEN SWIOTLB for ARM callbacks. dma_mmap patch is a port of an

[Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

From: Andrii Anisov Signed-off-by: Andrii Anisov --- arch/arm/xen/mm.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index ff812a2..dc83a35 100644 --- a/arch/arm/xen/mm.c +++

[Xen-devel] [PATCH v2 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

From: Stefano Stabellini This function creates userspace mapping for the DMA-coherent memory. Signed-off-by: Stefano Stabellini Signed-off-by: Oleksandr Dmytryshyn Signed-off-by: Andrii

Re: [Xen-devel] STAO spec in xen.git

Stefano Stabellini writes ("Re: STAO spec in xen.git"): > In that case, I think we should still commit it as ODT, but convert it > automatically to PDF when we publish it (we do something similar with > the markdown docs, converting them from markdown to html). Exactly. The fact that git diff

[Xen-devel] [PATCH 3/6] x86/cpuid: Move all xstate leaf handling into guest_cpuid()

The xstate union now contains sanitised values, so it can be handled fully in the non-legacy path. c/s 1c0bc709d "x86/cpuid: Perform max_leaf calculations in guest_cpuid()" accidentally introduced a boundary error for the subleaf check, although it was masked by the correct logic in the legacy

[Xen-devel] [PATCH 4/6] tools/libxc: Remove xsave calculations from libxc

libxc performs a lot of calculations for the xstate leaf when generating a guests cpuid policy. To correctly construct a policy for an HVM guest, this logic depends on native cpuid leaking through from real hardware. In particular, the logic is potentially wrong for an HVM-based toolstack domain

[Xen-devel] [PATCH 0/6] Further CPUID improvements

The main purpose of this series is move all all xstate handling to the non-legacy path. Andrew Cooper (6): x86/xstate: Fix array overrun on hardware with LWP x86/cpuid: Introduce recalculate_xstate() x86/cpuid: Move all xstate leaf handling into guest_cpuid() tools/libxc: Remove xsave

[Xen-devel] [PATCH 2/6] x86/cpuid: Introduce recalculate_xstate()

All data in the xstate union, other than the Da1 feature word, is derived from other state; either feature bits from other words, or layout information which has already been collected by Xen's xstate driver. Recalculate the xstate information for each policy object when the feature bits may have

[Xen-devel] [PATCH 5/6] x86/cpuid: Don't offer HVM hypervisor leaves to PV guests

Xen leaf 4 is HVM-only. Report a lower max_leaf to PV guests, so they don't go and investigate a leaf which will return all zeros. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/traps.c | 10 +++--- 1 file changed, 7

[Xen-devel] [PATCH 1/6] x86/xstate: Fix array overrun on hardware with LWP

c/s da62246e4c "x86/xsaves: enable xsaves/xrstors/xsavec in xen" introduced setup_xstate_features() to allocate and fill xstate_offsets[] and xstate_sizes[]. However, fls() casts xfeature_mask to 32bits which truncates LWP out of the calculation. As a result, the arrays are allocated too short,

[Xen-devel] [PATCH 6/6] x86/cpuid: Offer ITSC to domains which are automatically non-migrateable

Dom0 doesn't have a toolstack to explicitly decide that ITSC is safe to offer. For domains which are constructed with disable_migrate set, offer ITSC automatically. This is important for HVM-based dom0, and for when cpuid faulting is imposed on the control domain. Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 1/2] tools/xenstore: start with empty data base

On Tue, Jan 10, 2017 at 4:13 PM, Juergen Gross wrote: > - if (tdb_ctx) { > - /* XXX When we make xenstored able to restart, this will have Ah, the optimism of a young project. :-) -George ___ Xen-devel mailing

Re: [Xen-devel] PVH CPU hotplug design document

>>> On 14.01.17 at 02:44, wrote: > On 01/13/2017 10:51 AM, Jan Beulich wrote: > On 12.01.17 at 13:13, wrote: >>> # Introduction >>> >>> One of the design goals of PVH is to be able to remove as much Xen PV >>> specific >>> code as possible,

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

>>> On 13.01.17 at 18:40, wrote: > On 13/01/17 15:31, Jan Beulich wrote: >> @@ -5866,6 +5879,67 @@ x86_emulate( >> break; >> #endif >> >> +case X86EMUL_OPC_VEX(0x0f38, 0xf2):/* andn r/m,r,r */ >> +case X86EMUL_OPC_VEX(0x0f38, 0xf7):/* bextr

[Xen-devel] [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context

If the hardware supports faulting, and the guest has chosen to use it, leave faulting active in HVM context. It is more efficient to have hardware convert CPUID to a #GP fault (which we don't intercept), than to take a VMExit and have Xen re-inject a #GP fault. Signed-off-by: Andrew Cooper

Re: [Xen-devel] [OSSTEST PATCH v9 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

On Fri, Jan 13, 2017 at 07:38:28PM +, Ian Jackson wrote: > Ian Jackson writes ("Re: [OSSTEST PATCH v9 3/3] Create a flight to test > OpenStack with xen-unstable and libvirt"): > > Can you provide this series to me as a git branch (catch me on irc > > with the url perhaps) ? I will queue it

Re: [Xen-devel] [PATCH 5/8] x86emul: support TBM insns

>>> On 13.01.17 at 19:48, wrote: > On 13/01/17 15:32, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >> @@ -1355,6 +1355,7 @@ static bool vcpu_has( >> #define vcpu_has_cr8_legacy()

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

Boris Ostrovsky writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup"): > Hopefully I should be able to filter on "X-Osstest-Failures includes > "linux-linus:". Indeed. > > linux-linus > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ... > I think

Re: [Xen-devel] [PATCH 4/6] tools/libxc: Remove xsave calculations from libxc

On Mon, Jan 16, 2017 at 11:40:28AM +, Andrew Cooper wrote: > libxc performs a lot of calculations for the xstate leaf when generating a > guests cpuid policy. To correctly construct a policy for an HVM guest, this > logic depends on native cpuid leaking through from real hardware. > > In

Re: [Xen-devel] [PATCH 3/4] efi: create new early memory allocator

>>> On 13.01.17 at 20:21, wrote: > From: Daniel Kiper > > 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

[Xen-devel] [PATCH] x86/emul: Calculate not_64bit during instruction decode

... rather than repeating "generate_exception_if(mode_64bit(), EXC_UD);" in the emulation switch statement. Bloat-o-meter shows: add/remove: 0/0 grow/shrink: 1/2 up/down: 8/-495 (-487) function old new delta per_cpu__state

[Xen-devel] [PATCH v2 0/2] XEN SWIOTLB for ARM dma operations extension

From: Andrii Anisov Some drivers need additional dma ops to be provided by xen swiotlb. Because common operations implementation came from x86 world and does not suite ARM needs we have to provide needed XEN SWIOTLB for ARM callbacks. dma_mmap patch is a port of an

[Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

From: Andrii Anisov Signed-off-by: Andrii Anisov --- arch/arm/xen/mm.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index ff812a2..dc83a35 100644 --- a/arch/arm/xen/mm.c +++

[Xen-devel] [PATCH v2 1/2] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

From: Stefano Stabellini This function creates userspace mapping for the DMA-coherent memory. Signed-off-by: Stefano Stabellini Signed-off-by: Oleksandr Dmytryshyn Signed-off-by: Andrii

Re: [Xen-devel] [PATCH 0/4] multiboot2 protocol support

>>> On 13.01.17 at 20:21, wrote: > This is a series based on v11 of Daniel Kiper's > "x86: multiboot2 protocol support" series. It aims to collect up all the > fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in > code review and testing on actual

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

>>> On 16.01.17 at 10:25, wrote: > Here are some relevant logs, please help comment what's going on here and > what's the next step of diagnose. > It appears that the fault address 0xcfxx falls within the host RMRR > region. Might be a problem in the RMRR

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

>>> On 16.01.17 at 12:59, wrote: > On 16/01/17 11:19, Jan Beulich wrote: > On 13.01.17 at 18:40, wrote: >>> On 13/01/17 15:31, Jan Beulich wrote: @@ -5866,6 +5879,67 @@ x86_emulate( break; #endif +

Re: [Xen-devel] [PATCH] x86/pv: Check that emulate_privileged_op() don't change any unexpected flags

>>> On 16.01.17 at 14:03, wrote: > No bits, other than arithmetic ones and the resume flag (which will most > likely change from 1 to 0), can be changed by the instructions we permit. > Extend the check to cover other flags. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH V3] x86/HVM: Introduce struct hvm_pi_ops

Kevin, On 1/16/17 09:13, Tian, Kevin wrote: diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 7b2c50c..0854e17 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -103,6 +103,47 @@ void vmx_pi_per_cpu_init(unsigned int cpu)

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: > >>> On 16.01.17 at 10:25, wrote: > > Here are some relevant logs, please help comment what's going on here and > > what's the next step of diagnose. > > It appears that the fault address

Re: [Xen-devel] [PATCH V3] x86/HVM: Introduce struct hvm_pi_ops

>>> On 16.01.17 at 14:38, wrote: > So, what if I generalize and simplify as following: > > +/* > + * This structure defines function hooks to support hardware-assisted > + * virtual interrupt delivery to guest. (e.g. VMX PI and SVM AVIC). > + * > + * These hooks

[Xen-devel] [PATCH v2 2/3] xen: modify xenstore watch event interface

Today a Xenstore watch event is delivered via a callback function declared as: void (*callback)(struct xenbus_watch *, const char **vec, unsigned int len); As all watch events only ever come with two parameters (path and token) changing the prototype to: void (*callback)(struct

[Xen-devel] [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

Handling of multiple concurrent Xenstore accesses through xenbus driver either from the kernel or user land is rather lame today: xenbus is capable to have one access active only at one point of time. Rewrite xenbus to handle multiple requests concurrently by making use of the request id of the

[Xen-devel] [PATCH v2 0/3] xen: optimize xenbus performance

The xenbus driver used for communication with Xenstore (all kernel accesses to Xenstore and in case of Xenstore living in another domain all accesses of the local domain to Xenstore) is rather simple especially regarding multiple concurrent accesses: they are just being serialized in spite of

[Xen-devel] [PATCH v2 3/5] efi: create new early memory allocator

From: Daniel Kiper 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

[Xen-devel] [PATCH v2 0/5] multiboot2 protocol support

This is a series based on v11 of Daniel Kiper's "x86: multiboot2 protocol support" series. It aims to collect up all the fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in code review and testing on actual hardware. I've had problems with the relocation portion of the

[Xen-devel] [PATCH v2 4/5] x86: add multiboot2 protocol support for EFI platforms

From: Daniel Kiper This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper Reviewed-by: Doug Goldstein Tested-by: Doug Goldstein

[Xen-devel] [PATCH v2 1/5] x86: add multiboot2 protocol support

From: Daniel Kiper 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

[Xen-devel] [PATCH v2 2/5] efi: build xen.gz with EFI code

From: Daniel Kiper 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

[Xen-devel] [PATCH v2 5/5] fix: add multiboot2 protocol support for EFI platforms

This should be squashed into the 4/4 patch 'x86: add multiboot2 protocol support for EFI platforms'. - fix incorrect assembly (identified by Andrew Cooper) - fix issue where the trampoline size was left as 0 and the way the memory is allocated for the trampolines we would go to the end of an

[Xen-devel] [PATCH v2 1/3] xen: clean up xenbus internal headers

The xenbus driver has an awful mixture of internally and globally visible headers: some of the internally used only stuff is defined in the global header include/xen/xenbus.h while some stuff defined in internal headers is used by other drivers, too. Clean this up by moving the externally used

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On 1/16/17 9:11 AM, Daniel Kiper wrote: > On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote: >> On 1/16/17 7:50 AM, Daniel Kiper wrote: >>> On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: >>> On 13.01.17 at 20:21, wrote: > Doug v1 - fix

Re: [Xen-devel] [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context

>>> On 16.01.17 at 12:17, wrote: > If the hardware supports faulting, and the guest has chosen to use it, leave > faulting active in HVM context. > > It is more efficient to have hardware convert CPUID to a #GP fault (which we > don't intercept), than to take a VMExit

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

>>> On 16.01.17 at 14:51, wrote: > Right. What happens in reality is this: > > --- Xen Test Framework --- > Environment: HVM 32bit (No paging) > Test VEX.W matching mode: > andn a5a5, ff00ff00 = 00cc00a5 > Test VEX.W opposite to mode: > andn a5a5, ff00ff00

Re: [Xen-devel] [PATCH v3 4/5] Xen: Select correct dom0 console

Hi Mark, On 03/01/17 17:29, Mark Rutland wrote: On Thu, Dec 15, 2016 at 12:27:17PM +, Andre Przywara wrote: From: Ian Campbell If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to the usual ttyAMA0 otherwise. Signed-off-by: Ian Campbell

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

>>> On 16.01.17 at 13:43, wrote: On 16.01.17 at 12:59, wrote: >> On 16/01/17 11:19, Jan Beulich wrote: >> On 13.01.17 at 18:40, wrote: On 13/01/17 15:31, Jan Beulich wrote: > @@ -5866,6 +5879,67 @@

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

>>> On 16.01.17 at 14:04, wrote: > The chageset/version/compile information is currently exported as a set of > function calls into a separate translation unit, which is inefficient for all > callers. > > Replace the function calls with externs pointing appropriately

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On 1/16/17 7:50 AM, Daniel Kiper wrote: > On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > On 13.01.17 at 20:21, wrote: >>> Doug v1 - fix incorrect assembly (identified by Andrew Cooper) >>> - fix issue where the trampoline size was left as 0 and the

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

>>> On 16.01.17 at 14:43, wrote: > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: >> >>> On 16.01.17 at 10:25, wrote: >> > Here are some relevant logs, please help comment what's going on here and >> >

Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

Hi Stefano, On 03/01/17 19:27, Stefano Stabellini wrote: On Wed, 28 Dec 2016, Julien Grall wrote: On 20/12/16 22:33, Stefano Stabellini wrote: On Tue, 20 Dec 2016, Julien Grall wrote: On 20/12/2016 00:54, Stefano Stabellini wrote: On Mon, 19 Dec 2016, Julien Grall wrote: On 16/12/2016

Re: [Xen-devel] [PATCH] x86/emul: Calculate not_64bit during instruction decode

>>> On 16.01.17 at 11:49, wrote: > ... rather than repeating "generate_exception_if(mode_64bit(), EXC_UD);" in > the emulation switch statement. > > Bloat-o-meter shows: > > add/remove: 0/0 grow/shrink: 1/2 up/down: 8/-495 (-487) > function

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > >>> On 13.01.17 at 20:21, wrote: > > Doug v1 - fix incorrect assembly (identified by Andrew Cooper) > > - fix issue where the trampoline size was left as 0 and the > > way the memory is allocated

[Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

The chageset/version/compile information is currently exported as a set of function calls into a separate translation unit, which is inefficient for all callers. Replace the function calls with externs pointing appropriately into .rodata, which allows all users to generate code referencing the

[Xen-devel] [PATCH] x86/pv: Check that emulate_privileged_op() don't change any unexpected flags

No bits, other than arithmetic ones and the resume flag (which will most likely change from 1 to 0), can be changed by the instructions we permit. Extend the check to cover other flags. Signed-off-by: Andrew Cooper --- CC: Jan Beulich v2: * Extend

Re: [Xen-devel] [PATCH] xen/common: Drop function calls for Xen compile/version information

On 16/01/17 13:18, Jan Beulich wrote: On 16.01.17 at 14:04, wrote: >> The chageset/version/compile information is currently exported as a set of >> function calls into a separate translation unit, which is inefficient for all >> callers. >> >> Replace the function

Re: [Xen-devel] [PATCH V3] x86/HVM: Introduce struct hvm_pi_ops

Jan, I would like to updated the following to be more correct. On 1/12/17 19:37, Jan Beulich wrote: On 12.01.17 at 05:47, wrote: --- a/xen/include/asm-x86/hvm/domain.h +++ b/xen/include/asm-x86/hvm/domain.h @@ -72,6 +72,38 @@ struct hvm_ioreq_server {

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On 1/16/17 7:02 AM, Jan Beulich wrote: On 13.01.17 at 20:21, wrote: >> Doug v1 - fix incorrect assembly (identified by Andrew Cooper) >> - fix issue where the trampoline size was left as 0 and the >> way the memory is allocated for the trampolines we

[Xen-devel] Reading network data going into a VM from netback.c

Hi all, Recently, I’ve been trying to modify netback.c to print network data that is going into the VM. For example, I’m doing an SSL handshake with the VM as the server, and I send the following hexadecimal string from the client to the VM:

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

On 16/01/17 12:57, Jan Beulich wrote: On 16.01.17 at 13:43, wrote: > On 16.01.17 at 12:59, wrote: >>> On 16/01/17 11:19, Jan Beulich wrote: >>> On 13.01.17 at 18:40, wrote: > On 13/01/17 15:31, Jan Beulich

Re: [Xen-devel] [PATCH 3/4] efi: create new early memory allocator

On 1/16/17 6:52 AM, Jan Beulich wrote: On 13.01.17 at 20:21, wrote: >> From: Daniel Kiper >> >> 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.

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote: > On 1/16/17 7:50 AM, Daniel Kiper wrote: > > On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > > On 13.01.17 at 20:21, wrote: > >>> Doug v1 - fix incorrect assembly (identified by Andrew Cooper) >

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

On 16/01/17 13:58, Jan Beulich wrote: On 16.01.17 at 14:51, wrote: >> Right. What happens in reality is this: >> >> --- Xen Test Framework --- >> Environment: HVM 32bit (No paging) >> Test VEX.W matching mode: >> andn a5a5, ff00ff00 = 00cc00a5 >> Test VEX.W

Re: [Xen-devel] PVH CPU hotplug design document

On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote: > >>> On 12.01.17 at 13:13, wrote: > > # Introduction > > > > One of the design goals of PVH is to be able to remove as much Xen PV > > specific > > code as possible, thus limiting the number of Xen PV interfaces

Re: [Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

On Mon, Jan 16, 2017 at 09:28:45AM -0500, Doug Goldstein wrote: > On 1/16/17 9:11 AM, Daniel Kiper wrote: > > On Mon, Jan 16, 2017 at 08:41:08AM -0500, Doug Goldstein wrote: > >> On 1/16/17 7:50 AM, Daniel Kiper wrote: > >>> On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote: > >>> On

Re: [Xen-devel] STAO spec in xen.git

On Mon, Jan 16, 2017 at 11:26:57AM +, Ian Jackson wrote: > Stefano Stabellini writes ("Re: STAO spec in xen.git"): > > In that case, I think we should still commit it as ODT, but convert it > > automatically to PDF when we publish it (we do something similar with > > the markdown docs,

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

On Fri, Jan 13, 2017 at 04:27:52PM +, Ian Jackson wrote: > Boris Ostrovsky writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = > can't bootup"): > > I can give it a try although I have practically no experience with > > OSSTest. Is there a way to subscribe to notifications for those

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

>>> On 16.01.17 at 15:17, wrote: > On 16/01/17 13:58, Jan Beulich wrote: > On 16.01.17 at 14:51, wrote: >>> Right. What happens in reality is this: >>> >>> --- Xen Test Framework --- >>> Environment: HVM 32bit (No paging) >>> Test VEX.W

Re: [Xen-devel] [PATCH 5/8] x86emul: support TBM insns

>>> On 16.01.17 at 15:52, wrote: > On 16/01/17 11:36, Jan Beulich wrote: > On 13.01.17 at 19:48, wrote: >>> On 13/01/17 15:32, Jan Beulich wrote: --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++

Re: [Xen-devel] [PATCH v3 3/8] dm_op: convert HVMOP_track_dirty_vram

On 12/01/17 14:58, Paul Durrant wrote: > The handle type passed to the underlying shadow and hap functions is > changed for compatibility with the new hypercall buffer. > > NOTE: This patch also modifies the type of the 'nr' parameter of > xc_hvm_track_dirty_vram() from uint64_t to

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote: > >>> On 16.01.17 at 14:43, wrote: > > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: > >> >>> On 16.01.17 at 10:25, wrote: > >

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

BTW, before I generate more verbose && complete debug log, just want to update that I also see the following in dom0 (without attempting any pass-through to the IGD device) But this time the log is not flooding at all. Not sure if this is relevant to what I see from the domU with pci pass-through.

Re: [Xen-devel] [OSSTEST PATCH v9 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

Anthony PERARD writes ("Re: [OSSTEST PATCH v9 3/3] Create a flight to test OpenStack with xen-unstable and libvirt"): > Here, it is downloading pip. There's maybe a way to not make it do that. > I'll try to find out. But I think more stuff are going to be downloaded, > all the python packages,

Re: [Xen-devel] [PATCH v2 2/2] x86/cpuid: Move x86_vendor from arch_domain to cpuid_policy

On 13/01/17 13:56, Andrew Cooper wrote: > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Tim Deegan > CC: George Dunlap > CC: Paul Durrant >

Re: [Xen-devel] PVH CPU hotplug design document

On Fri, Jan 13, 2017 at 08:27:30AM -0700, Jan Beulich wrote: > >>> On 12.01.17 at 20:00, wrote: > > On 12/01/17 12:13, Roger Pau Monné wrote: > >> Extra entries are going to be added for each vCPU available to the hardware > >> domain, up to the maximum number of

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

On Mon, Jan 16, 2017 at 1:43 PM, G.R. wrote: > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: >> >> >>> On 16.01.17 at 10:25, wrote: >> > Here are some relevant logs, please help comment what's going on

Re: [Xen-devel] PVH CPU hotplug design document

On Thu, Jan 12, 2017 at 07:00:57PM +, Andrew Cooper wrote: > On 12/01/17 12:13, Roger Pau Monné wrote: [...] > > ## QEMU CPU hotplug using ACPI > > > > The ACPI tables provided to HVM guests contain processor objects, as > > created by > > libacpi. The number of processor objects in the ACPI

Re: [Xen-devel] [PATCH 5/8] x86emul: support TBM insns

On 16/01/17 11:36, Jan Beulich wrote: On 13.01.17 at 19:48, wrote: >> On 13/01/17 15:32, Jan Beulich wrote: >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c >>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c >>> @@ -1355,6 +1355,7 @@ static bool vcpu_has( >>>

Re: [Xen-devel] [PATCH v6 01/14] generic-sections: add section core helpers

On Mon, Jan 09, 2017 at 06:58:19AM -0800, Luis R. Rodriguez wrote: > Linux makes extensive use of custom ELF header sections, > documentation for these are well scatterred. Unify this is > documentation in a central place and provide helpers to > build custom Linux

Re: [Xen-devel] [PATCH V2] Xen: ARM: Zero reserved fields of xatp before making hypervisor call

Hi Stefano, On 03/01/17 18:03, Stefano Stabellini wrote: On Mon, 2 Jan 2017, Juergen Gross wrote: On 28/12/16 01:47, Jiandi An wrote: Ensure all reserved fields of xatp are zero before making hypervisor call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in XEN fails the mapping

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

Roger Pau Monné writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup"): > Shouldn't this be: > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Err, yes, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

On 13/01/17 12:47, Jan Beulich wrote: > The kernel already has to parse this structure anyway, and will know the > bitness of its userspace process. We could easily (at this point) > require the kernel to turn it into the kernels bitness for forwarding on > to Xen, which covers

Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

>>> On 16.01.17 at 17:05, wrote: > On 13/01/17 12:47, Jan Beulich wrote: >> The kernel already has to parse this structure anyway, and will know the >> bitness of its userspace process. We could easily (at this point) >> require the kernel to turn it into

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

>>> On 16.01.17 at 16:21, wrote: > BTW, before I generate more verbose && complete debug log, just want to > update that I also see the following in dom0 (without attempting any > pass-through to the IGD device) > But this time the log is not flooding at all. Not

Re: [Xen-devel] [PATCH v2 3/4] arm, vgic_migrate_irq: take the right vgic lock

Hi Stefano, On 03/01/17 23:30, Stefano Stabellini wrote: On Wed, 28 Dec 2016, Julien Grall wrote: On 22/12/16 02:15, Stefano Stabellini wrote: Always take the vgic lock of the old vcpu. When more than one irq migration is requested before the first one completes, take the vgic lock of the

Re: [Xen-devel] PVH CPU hotplug design document

On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote: > >>> On 16.01.17 at 16:14, wrote: > > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote: > >> >>> On 12.01.17 at 13:13, wrote: > >> > # Introduction > >> > > >> > One of the

Re: [Xen-devel] PVH CPU hotplug design document

>>> On 16.01.17 at 16:14, wrote: > On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote: >> >>> On 12.01.17 at 13:13, wrote: >> > # Introduction >> > >> > One of the design goals of PVH is to be able to remove as much Xen PV >> > specific >> >

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

>>> On 16.01.17 at 16:15, wrote: > On Mon, Jan 16, 2017 at 9:56 PM, Jan Beulich wrote: > >> >>> On 16.01.17 at 14:43, wrote: >> > On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote: >> >>

Re: [Xen-devel] [PATCH 1/6] x86/xstate: Fix array overrun on hardware with LWP

>>> On 16.01.17 at 12:40, wrote: > c/s da62246e4c "x86/xsaves: enable xsaves/xrstors/xsavec in xen" introduced > setup_xstate_features() to allocate and fill xstate_offsets[] and > xstate_sizes[]. > > However, fls() casts xfeature_mask to 32bits which truncates LWP out

  1   2   >