[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemut-rhel6hvm-intel

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-qemut-rhel6hvm-intel testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

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

flight 120709 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120709/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 120679 build-armhf

[Xen-devel] [rumprun test] 120583: regressions - FAIL

flight 120583 rumprun real [real] http://logs.test-lab.xenproject.org/osstest/logs/120583/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754 build-i386-rumprun

[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm

branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-arm64-xsm testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug

Re: [Xen-devel] [PATCH] xenbaked.c: Avoid divide by zero issue on dump_stats()

On Tue, Mar 13, 2018 at 06:38:24PM -0700, Joe Jin wrote: > run_time on dump_stats() maybe zero if break xenmon.py immediately after it s/maybe/can be/ > started, then xenbaked hit divide by zero fault. And: "Note that run_time is computed using two values which are retrieved using 'time'

[Xen-devel] [PATCH] xenbaked.c: Avoid divide by zero issue on dump_stats()

run_time on dump_stats() maybe zero if break xenmon.py immediately after it started, then xenbaked hit divide by zero fault. Signed-off-by: Joe Jin Signed-off-by: Konrad Rzeszutek Wilk Cc: Wei Liu Cc: Ian Campbell

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

flight 120699 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120699/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 120679 build-armhf

[Xen-devel] [xen-4.10-testing test] 120559: regressions - FAIL

flight 120559 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120559/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-buildfail REGR. vs. 120244

Re: [Xen-devel] Regression with commit "x86/pv: Drop int80_bounce from struct pv_vcpu" f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1

On 13/03/2018 23:28, Sander Eikelenboom wrote: > On 13/03/18 23:01, Andrew Cooper wrote: >> On 10/03/18 16:14, Sander Eikelenboom wrote: >>> Hi Andrew, >>> >>> It seems commit "x86/pv: Drop int80_bounce from struct pv_vcpu" >>> (f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1) causes an issue on my

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

Hi Oleksandr, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180313] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

[Xen-devel] [RFC PATCH] drm/xen-front: xen_drm_front_platform_info can be static

Fixes: db81084f9084 ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by: Fengguang Wu --- xen_drm_front.c |2 +- xen_drm_front_drv.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xen/xen_drm_front.c

Re: [Xen-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device support for Q35

On Mon, 12 Mar 2018 18:44:02 -0300 Eduardo Habkost wrote: >On Tue, Mar 13, 2018 at 06:56:37AM +1000, Alexey G wrote: >> On Mon, 12 Mar 2018 16:44:06 -0300 >> Eduardo Habkost wrote: >> >> >On Tue, Mar 13, 2018 at 04:34:01AM +1000, Alexey Gerasimenko

[Xen-devel] [PATCH v2 2/4] libxl: Move libxl__arch_domain_construct_memmap() earlier

From: Boris Ostrovsky Since hvm_start_info has now been expanded to include PVH guest's memory map (i.e. e820) we need to know size of this map by the time we create dom->start_info_seg in alloc_magic_pages_hvm(). To do so we have to call

[Xen-devel] [PATCH v2 0/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

Here is the patch series for updating the canonical definition of the hvm_start_info struct corresponding to the discussion happening on the linux-kernel and kvm mailing lists regarding Qemu/KVM use of the PVH entry point: KVM: x86: Allow Qemu/KVM to use PVH entry point

[Xen-devel] [PATCH v2 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. Signed-off-by:

[Xen-devel] [PATCH v2 3/4] libxl: Store PVH guest's e820 map in xc_dom_image

From: Boris Ostrovsky We will later copy it to hvm_start_info. (Also remove stale comment claming that xc_dom_image.start_info_seg is only used for HVMlite guests) Signed-off-by: Boris Ostrovsky --- tools/libxc/include/xc_dom.h | 8

[Xen-devel] [PATCH v2] xen-pvdevice: Introduce a simplistic xen-pvdevice save state

This should help to avoid problems with accessing the device after migration/resume without PV drivers by migrating its PCI configuration space state. Without an explicitly defined state record it resets every time a VM migrates which confuses the OS and makes every access to xen-pvdevice MMIO

Re: [Xen-devel] Regression with commit "x86/pv: Drop int80_bounce from struct pv_vcpu" f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1

On 10/03/18 16:14, Sander Eikelenboom wrote: > Hi Andrew, > > It seems commit "x86/pv: Drop int80_bounce from struct pv_vcpu" > (f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1) causes an issue on my machine, > an AMD phenom X6. > > When trying to installing a new kernel package which runs the Debian >

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

flight 120688 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120688/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 120679 build-armhf

[Xen-devel] [xen-4.8-testing test] 120544: regressions - FAIL

flight 120544 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120544/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116 build-armhf

[Xen-devel] [PATCH] [v3] xen: remove pre-xen3 fallback handlers

The legacy hypercall handlers were originally added with a comment explaining that "copying the argument structures in HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local variable is sufficiently safe" and only made sure to not write past the end of the argument structure, the

[Xen-devel] [PATCH v2 19/27] kvm: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. The new __ASM_MOVABS macro is used to get the address of a symbol on both 32 and 64-bit with PIE support. Position Independent Executable (PIE) support will allow to extended the KASLR

[Xen-devel] [PATCH v2 20/27] x86: Support global stack cookie

Add an off-by-default configuration option to use a global stack cookie instead of the default TLS. This configuration option will only be used with PIE binaries. For kernel stack cookie, the compiler uses the mcmodel=kernel to switch between the fs segment to gs segment. A PIE binary does not

[Xen-devel] [PATCH v2 24/27] x86/mm: Make the x86 GOT read-only

The GOT is changed during early boot when relocations are applied. Make it read-only directly. This table exists only for PIE binary. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier

[Xen-devel] [PATCH v2 26/27] x86/relocs: Add option to generate 64-bit relocations

The x86 relocation tool generates a list of 32-bit signed integers. There was no need to use 64-bit integers because all addresses where above the 2G top of the memory. This change add a large-reloc option to generate 64-bit unsigned integers. It can be used when the kernel plan to go below the

[Xen-devel] [PATCH v2 18/27] xen: Adapt assembly for PIE support

Change the assembly code to use the new _ASM_MOVABS macro which get a symbol reference while being PIE compatible. Adapt the relocation tool to ignore 32-bit Xen code. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit.

[Xen-devel] [PATCH v2 27/27] x86/kaslr: Add option to extend KASLR range from 1GB to 3GB

Add a new CONFIG_RANDOMIZE_BASE_LARGE option to benefit from PIE support. It increases the KASLR range from 1GB to 3GB. The new range stars at 0x just above the EFI memory region. This option is off by default. The boot code is adapted to create the appropriate page table spanning

[Xen-devel] [PATCH v2 25/27] x86/pie: Add option to build the kernel as PIE

Add the CONFIG_X86_PIE option which builds the kernel as a Position Independent Executable (PIE). The kernel is currently build with the mcmodel=kernel option which forces it to stay on the top 2G of the virtual address space. With PIE, the kernel will be able to move below the current limit. The

[Xen-devel] [PATCH v2 21/27] x86/ftrace: Adapt function tracing for PIE support

When using -fPIE/PIC with function tracing, the compiler generates a call through the GOT (call *__fentry__@GOTPCREL). This instruction takes 6 bytes instead of 5 on the usual relative call. If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop so ftrace can handle the previous

[Xen-devel] [PATCH v2 22/27] x86/modules: Add option to start module section after kernel

Add an option so the module section is just after the mapped kernel. It will ensure position independent modules are always at the right distance from the kernel and do not require mcmodule=large. It also optimize the available size for modules by getting rid of the empty space on kernel

[Xen-devel] [PATCH v2 11/27] x86/power/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier ---

[Xen-devel] [PATCH v2 13/27] x86/boot/64: Build head64.c as mcmodel large when PIE is enabled

The __startup_64 function assumes all symbols have relocated addresses instead of the current boot virtual address. PIE generated code favor relative addresses making all virtual and physical address math incorrect. If PIE is enabled, build head64.c as mcmodel large instead to ensure absolute

[Xen-devel] [PATCH v2 17/27] x86/relocs: Handle PIE relocations

Change the relocation tool to correctly handle relocations generated by -fPIE option: - Add relocation for each entry of the .got section given the linker does not generate R_X86_64_GLOB_DAT on a simple link. - Ignore R_X86_64_GOTPCREL. Signed-off-by: Thomas Garnier

[Xen-devel] [PATCH v2 10/27] x86/boot/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Early at boot, the kernel is mapped at a temporary address while preparing the page table. To know the changes needed for the page table with KASLR, the boot code calculate the difference

[Xen-devel] [PATCH v2 09/27] x86/acpi: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier ---

[Xen-devel] [PATCH v2 12/27] x86/paravirt: Adapt assembly for PIE support

if PIE is enabled, switch the paravirt assembly constraints to be compatible. The %c/i constrains generate smaller code so is kept by default. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas

[Xen-devel] [PATCH v2 06/27] x86/entry/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier ---

[Xen-devel] [PATCH v2 03/27] x86: Use symbol name in jump table for PIE support

Replace the %c constraint with %P. The %c is incompatible with PIE because it implies an immediate value whereas %P reference a symbol. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier

[Xen-devel] [PATCH v2 16/27] compiler: Option to add PROVIDE_HIDDEN replacement for weak symbols

Provide an option to have a PROVIDE_HIDDEN (linker script) entry for each weak symbol. This option solve an error in x86_64 where the linker optimizes pie generate code to be non-pie because --emit-relocs was used instead of -pie (to reduce dynamic relocations). Signed-off-by: Thomas Garnier

[Xen-devel] [PATCH v2 07/27] x86: pm-trace - Adapt assembly for PIE support

Change assembly to use the new _ASM_MOVABS macro instead of _ASM_MOV for the assembly to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier ---

[Xen-devel] [PATCH v2 15/27] compiler: Option to default to hidden symbols

Provide an option to default visibility to hidden except for key symbols. This option is disabled by default and will be used by x86_64 PIE support to remove errors between compilation units. The default visibility is also enabled for external symbols that are compared as they maybe equals

[Xen-devel] [PATCH v2 05/27] x86: relocate_kernel - Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier ---

[Xen-devel] [PATCH v2 01/27] x86/crypto: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier ---

[Xen-devel] [PATCH v2 00/27] x86: PIE support and option to extend KASLR randomization

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc

[Xen-devel] [PATCH v2 04/27] x86: Add macro to get symbol address for PIE support

Add a new _ASM_MOVABS macro to fetch a symbol address. It will be used to replace "_ASM_MOV $, %dst" code construct that are not compatible with PIE. Signed-off-by: Thomas Garnier --- arch/x86/include/asm/asm.h | 1 + 1 file changed, 1 insertion(+) diff --git

[Xen-devel] [PATCH v2 02/27] x86: Use symbol name on bug table for PIE support

Replace the %c constraint with %P. The %c is incompatible with PIE because it implies an immediate value whereas %P reference a symbol. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier

Re: [Xen-devel] [PATCHv3] xen: Add EFI_LOAD_OPTION support

On Tue, Mar 13, 2018 at 1:47 AM, Jan Beulich wrote: On 12.03.18 at 16:00, wrote: >> Patch ping. Jan, I would like to touch base once more to see if we can >> get this patch included in 4.11. The patch as-is correctly tells the >> difference between

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Final Agenda

Hi all, Please find attached the agenda We don’t have any design and problem related items this meeting. This means that we will only cover discussions specific to some series, some may contain design related discussion though. Note that the meeting will probably not be very interesting for

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

flight 120685 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120685/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 120679 build-armhf

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

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

[Xen-devel] [PATCH v5 2/2] xl: Register the AER event handler that handles AER errors

When a guest is created, register the AER event handler to handle the AER errors. When an AER error occurs, the handler will forcibly remove the erring PCIe device from the guest. Signed-off-by: Venu Busireddy Signed-off-by: Wim Ten Have ---

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

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

Re: [Xen-devel] Modifying domain creation interface

On 13/03/18 17:08, Wei Liu wrote: > On Wed, Feb 21, 2018 at 03:08:23PM +0100, Juergen Gross wrote: >> Creating a new domain currently is a sequence of hypercalls with many of >> those being mandatory and needed in a specific sequence. Its has been >> discussed before to build a new interface for

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On 3/13/2018 10:16 AM, Roger Pau Monné wrote: On Tue, Mar 13, 2018 at 09:55:20AM -0700, Maran Wilson wrote: On 3/13/2018 9:34 AM, Jan Beulich wrote: On 13.03.18 at 17:20, wrote: On 3/13/2018 3:50 AM, Roger Pau Monné wrote: On Fri, Mar 02, 2018 at 12:54:29PM -0800,

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On 13/03/18 18:51, Boris Ostrovsky wrote: > > > On 03/13/2018 01:27 AM, Juergen Gross wrote: >> On 12/03/18 20:26, Sander Eikelenboom wrote: >>> Hi Juergen, >>> >>> I don't know by which tree those patches should arrive at Linus, >>> so i can't check if they fell through the cracks somewhere,

Re: [Xen-devel] [RFC PATCH 03/12] hvmloader: add function to query an emulated machine type (i440/Q35)

On Wed, Mar 14, 2018 at 03:58:17AM +1000, Alexey G wrote: > On Tue, 13 Mar 2018 17:26:04 + > Wei Liu wrote: > > >On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote: > >> This adds a new function get_pc_machine_type() which allows to > >> determine the

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On 03/13/2018 01:27 AM, Juergen Gross wrote: On 12/03/18 20:26, Sander Eikelenboom wrote: Hi Juergen, I don't know by which tree those patches should arrive at Linus, so i can't check if they fell through the cracks somewhere, but 4.16-rc5 hasn't got them yet. They are queued for 4.17 in:

Re: [Xen-devel] [RFC PATCH 03/12] hvmloader: add function to query an emulated machine type (i440/Q35)

On Tue, 13 Mar 2018 17:26:04 + Wei Liu wrote: >On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote: >> This adds a new function get_pc_machine_type() which allows to >> determine the emulated chipset type. Supported return values: >> >> -

Re: [Xen-devel] [PATCH 1/2] libxl: Add a version check of QEMU for QMP commands

On Tue, Mar 13, 2018 at 05:40:08PM +, Wei Liu wrote: > On Tue, Mar 13, 2018 at 11:13:17AM +, Anthony PERARD wrote: > > On connection to QEMU via QMP, the version of QEMU is provided, store it > > for later use. > > > > Add a function qmp_qemu_check_version that can be used to check if

Re: [Xen-devel] [PATCH v10] x86/altp2m: support for setting restrictions for an array of pages

On Wed, Dec 13, 2017 at 04:22:20PM +0200, Petre Pircalabu wrote: > /** > * Mem paging operations. > diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c > index 07fcd18..0f792b5 100644 > --- a/tools/libxc/xc_altp2m.c > +++ b/tools/libxc/xc_altp2m.c > @@ -213,3 +213,44 @@ int

Re: [Xen-devel] [PATCH 2/2] libxl_qmp: Tell QEMU about live migration or snapshot

On Tue, Mar 13, 2018 at 11:13:18AM +, Anthony PERARD wrote: > Since version 2.10, QEMU will lock the disk images so a second QEMU > instance will not try to open it. This would prevent live migration from > working correctly. A new parameter as been added to the QMP command >

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On Tue, Mar 13, 2018 at 09:55:20AM -0700, Maran Wilson wrote: > On 3/13/2018 9:34 AM, Jan Beulich wrote: > > > > > On 13.03.18 at 17:20, wrote: > > > On 3/13/2018 3:50 AM, Roger Pau Monné wrote: > > > > On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote: > > > >

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

Hi, On 13/03/18 17:34, Andre Przywara wrote: On 13/03/18 17:14, Julien Grall wrote: On 13/03/18 17:02, Andre Przywara wrote: On 08/03/18 15:39, Julien Grall wrote: On 05/03/18 16:03, Andre Przywara wrote: I can't see how a knowledgeable admin will be able to know that IRQ 2 is active with

Re: [Xen-devel] [PATCH 1/2] libxl: Add a version check of QEMU for QMP commands

On Tue, Mar 13, 2018 at 11:13:17AM +, Anthony PERARD wrote: > On connection to QEMU via QMP, the version of QEMU is provided, store it > for later use. > > Add a function qmp_qemu_check_version that can be used to check if QEMU > is new enough for certain fonctionnality. This will be used in

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

Hi, On 13/03/18 17:14, Julien Grall wrote: > Hi Andre, > > On 13/03/18 17:02, Andre Przywara wrote: >> On 08/03/18 15:39, Julien Grall wrote: >>> On 05/03/18 16:03, Andre Przywara wrote: +/* + * We don't actually support clearing the active state of an IRQ (yet). + * However

Re: [Xen-devel] [RFC PATCH 08/12] libxl: Q35 support (new option device_model_machine)

On Tue, Mar 13, 2018 at 05:25:50PM +, Wei Liu wrote: > Cc Anthony > > IIRC there are changes needed on QEMU side? Yes, there are actually QEMU patches in the patch series. I'm CCed on them. > Do we need to wait until that lands? That's depends. I don't have an answer. -- Anthony PERARD

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On 03/13/2018 06:31 PM, Takashi Iwai wrote: On Tue, 13 Mar 2018 12:49:00 +0100, Oleksandr Andrushchenko wrote: So, I tried to make a POC to stress the protocol changes and see what implementation of the HW parameter negotiation would look like. Please find protocol changes at [1]: - add

Re: [Xen-devel] [PATCH] xl/libxl: add pvcalls support

On Tue, 13 Mar 2018, George Dunlap wrote: > On Tue, Mar 13, 2018 at 2:13 PM, Wei Liu wrote: > > On Tue, Feb 27, 2018 at 01:28:08PM -0800, Stefano Stabellini wrote: > >> Add pvcalls support to libxl and xl. Create the appropriate pvcalls > >> entries in xenstore. > >> > >>

Re: [Xen-devel] [RFC PATCH 04/12] hvmloader: add ACPI enabling for Q35

On Tue, Mar 13, 2018 at 04:33:49AM +1000, Alexey Gerasimenko wrote: > In order to turn on ACPI for OS, we need to write a chipset-specific value > to SMI_CMD register (sort of imitation of the APM->ACPI switch on real > systems). Modify acpi_enable_sci() function to support both i440 and Q35 >

Re: [Xen-devel] [RFC PATCH 08/12] libxl: Q35 support (new option device_model_machine)

Cc Anthony IIRC there are changes needed on QEMU side? Do we need to wait until that lands? Wei. On Tue, Mar 13, 2018 at 04:33:53AM +1000, Alexey Gerasimenko wrote: > Provide a new domain config option to select the emulated machine type, > device_model_machine. It has following possible

Re: [Xen-devel] [RFC PATCH 03/12] hvmloader: add function to query an emulated machine type (i440/Q35)

On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote: > This adds a new function get_pc_machine_type() which allows to determine > the emulated chipset type. Supported return values: > > - MACHINE_TYPE_I440 > - MACHINE_TYPE_Q35 > - MACHINE_TYPE_UNKNOWN, results in the error message

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

On 13/03/18 17:14, Julien Grall wrote: On 13/03/18 17:02, Andre Przywara wrote: On 08/03/18 15:39, Julien Grall wrote: On 05/03/18 16:03, Andre Przywara wrote: I admit the bailout is a bit weird here. You would only print the warning for the first activated IRQ and give the impression it is

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

Hi Andre, On 13/03/18 17:02, Andre Przywara wrote: On 08/03/18 15:39, Julien Grall wrote: On 05/03/18 16:03, Andre Przywara wrote: +/* + * We don't actually support clearing the active state of an IRQ (yet). + * However there is a chance that most guests use this for initialization. + * We

Re: [Xen-devel] [PATCH v4] new config option vtsc_tolerance_khz to avoid TSC emulation

On Fri, Mar 09, 2018 at 03:10:39PM +0100, Olaf Hering wrote: > Add an option to control when vTSC emulation will be activated for a > domU with tsc_mode=default. Without such option each TSC access from > domU will be emulated, which causes a significant perfomance drop for > workloads that make

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

Hi, On 08/03/18 15:39, Julien Grall wrote: > Hi Andre, > > On 05/03/18 16:03, Andre Przywara wrote: >> The active register handlers are shared between the v2 and v3 emulation, >> so their implementation goes into vgic-mmio.c, to be easily referenced >> from the v3 emulation as well later. >>

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On 3/13/2018 9:34 AM, Jan Beulich wrote: On 13.03.18 at 17:20, wrote: On 3/13/2018 3:50 AM, Roger Pau Monné wrote: On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote: @@ -62,10 +72,34 @@ *| reserved | * 32 ++ * + * The

Re: [Xen-devel] [PATCH v10] x86/altp2m: support for setting restrictions for an array of pages

>>> On 13.12.17 at 15:22, wrote: > From: Razvan Cojocaru > > For the default EPT view we have xc_set_mem_access_multi(), which > is able to set an array of pages to an array of access rights with > a single hypercall. However, this

Re: [Xen-devel] [PATCH] xl: remove apic option for PVH guests

On Tue, Mar 13, 2018 at 02:23:15PM +, Roger Pau Monné wrote: > On Mon, Mar 05, 2018 at 11:36:58AM +, Ian Jackson wrote: > > Roger Pau Monne writes ("[PATCH] xl: remove apic option for PVH guests"): > > > XSA-256 forces the local APIC to always be enabled for PVH guests, so > > > ignore any

Re: [Xen-devel] Modifying domain creation interface

On Wed, Feb 21, 2018 at 03:08:23PM +0100, Juergen Gross wrote: > Creating a new domain currently is a sequence of hypercalls with many of > those being mandatory and needed in a specific sequence. Its has been > discussed before to build a new interface for domain creation with _all_ > the

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

>>> On 13.03.18 at 17:20, wrote: > On 3/13/2018 3:50 AM, Roger Pau Monné wrote: >> On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote: >>> @@ -62,10 +72,34 @@ >>>*| reserved | >>>* 32 ++ >>>* >>> + * The layout of each entry

Re: [Xen-devel] [PATCH v2] tools/xl: fix uninitialized variable in xl_vdispl

On Tue, Mar 13, 2018 at 11:25:29AM -0500, Doug Goldstein wrote: > The code added in 7a48622a78a0b452e8afa55b8442c958abd226a7 could use rc > uninitialized in main_vdisplattach(). > > Signed-off-by: Doug Goldstein Acked-by: Wei Liu

Re: [Xen-devel] [alsa-devel] [PATCH 0/2] sndif: add explicit back and front synchronization

On Tue, 13 Mar 2018 12:49:00 +0100, Oleksandr Andrushchenko wrote: > > So, I tried to make a POC to stress the protocol changes and see > what implementation of the HW parameter negotiation would look like. > > Please find protocol changes at [1]: > - add XENSND_OP_HW_PARAM_QUERY request to

Re: [Xen-devel] [PATCH 1/1] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On 3/13/2018 3:50 AM, Roger Pau Monné wrote: On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote: The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information

Re: [Xen-devel] [PATCH v2 1/5] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

>>> On 13.03.18 at 16:47, wrote: > On 13/03/18 15:20, Jan Beulich wrote: > On 07.03.18 at 19:58, wrote: >>> @@ -175,11 +177,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, > uint64_t *val) >>>

[Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Add support for Xen para-virtualized frontend display driver. Accompanying backend [1] is implemented as a user-space application and its helper library [2], capable of running as a Weston client or DRM master. Configuration of both

[Xen-devel] [PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Hello! Resending with all the patches squashed on Daniel's request. This patch series adds support for Xen [1] para-virtualized frontend display driver. It implements the protocol from include/xen/interface/io/displif.h [2].

[Xen-devel] [PATCH RESEND v2 2/2] drm/xen-front: Provide kernel documentation

From: Oleksandr Andrushchenko Provide kernel documentation for the Xen para-virtualized frontend DRM driver. Signed-off-by: Oleksandr Andrushchenko --- Documentation/gpu/index.rst | 1 + Documentation/gpu/xen-front.rst |

Re: [Xen-devel] [PATCH v6 7/9] x86/mm: provide put_page_type_ptpg{, _preemptible}

>>> On 13.02.18 at 21:04, wrote: > @@ -2736,8 +2744,8 @@ int put_old_guest_table(struct vcpu *v) > if ( !v->arch.old_guest_table ) > return 0; > > -switch ( rc = _put_page_type(v->arch.old_guest_table, true, > -

Re: [Xen-devel] [RFC PATCH 6/6] ci: add a README about the containers

On 3/13/18 10:38 AM, George Dunlap wrote: > On 03/13/2018 03:31 AM, Doug Goldstein wrote: >> Add a basic README explaining the containers and how people can use them >> to locally test with if they see an error in CI and want to reproduce it >> locally. >> >> Signed-off-by: Doug Goldstein

Re: [Xen-devel] [PATCH v6 7/9] x86/mm: provide put_page_type_ptpg{, _preemptible}

>>> On 13.02.18 at 21:04, wrote: > And replace open-coded _put_page_type where the parent table parameter > is not null. > > This is in preparation for code movement in which various > put_page_from_lNe will be moved to pv/mm.c. I dislike both the proliferation of new

Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

On 12/03/18 17:33, Amit Tomer wrote: Hi, Hi, This is quite useful to get output without any serial driver. I am quite impressed you managed to debug your serial driver without it :). Actually, we have earlycon=xenboot(suggested by Andre) enabled in Dom0 bootargs and it allowed us to

Re: [Xen-devel] [PATCH v6 6/9] x86/mm: export set_tlbflush_timestamp

>>> On 13.02.18 at 21:04, wrote: > The function will skip stamping the page when the page is used as page > table in shadow mode. Since it is called both in PV code and common > code we need to export it. Again I think there's some prerequisite analysis necessary: Is this

Re: [Xen-devel] [PATCH v2 1/5] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

On 13/03/18 15:20, Jan Beulich wrote: On 07.03.18 at 19:58, wrote: >> @@ -175,11 +177,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, >> uint64_t *val) >> _MSR_MISC_FEATURES_CPUID_FAULTING; >> break; >> >> +case

Re: [Xen-devel] [PATCH v6 5/9] x86/mm: factor out pv_dec_linear_pt

>>> On 13.02.18 at 21:04, wrote: > Linear page table is a PV only feature. The functions used to handle > that will be moved. But the functions dealing with linear page tables are all helpers to PV-only functions. Why does any of this need to become non- static or factored

Re: [Xen-devel] [PATCH v6 4/9] x86/mm: add pv prefix to _put_final_page_type

>>> On 13.02.18 at 21:04, wrote: > ... so that it is clear it is PV only and can be moved later. Same comment as on patch 1, plus - why does it need to become non-static? Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 51/57] ARM: new VGIC: Add preliminary stub implementation

Hi, On 09/03/18 18:18, Julien Grall wrote: > Hi Andre, > > On 05/03/18 16:04, Andre Przywara wrote: >> The ARM arch code requires an interrupt controller emulation to implement >> vgic_clear_pending_irqs(), although it is suspected that it is actually >> not necessary. Go with a stub for now to

Re: [Xen-devel] [RFC PATCH 0/6] Using GitLab CI for build testing

On Mon, Mar 12, 2018 at 11:29:47PM -0500, Doug Goldstein wrote: > On 3/12/18 10:31 PM, Doug Goldstein wrote: > > Really early work on switching over to using GitLab CI over > > Travis CI. GitLab is a competitor to GitHub with some advantages > > such as an integrated CI system with a lot more

Re: [Xen-devel] [RFC PATCH 6/6] ci: add a README about the containers

On 03/13/2018 03:31 AM, Doug Goldstein wrote: > Add a basic README explaining the containers and how people can use them > to locally test with if they see an error in CI and want to reproduce it > locally. > > Signed-off-by: Doug Goldstein > --- > extras/testing/README.md |

[Xen-devel] [PATCH 4.15 123/146] x86/xen: Calculate __max_logical_packages on PV domains

4.15-stable review patch. If anyone has any objections, please let me know. -- From: Prarit Bhargava commit 63e708f826bb21470155d37b103a75d8a9e25b18 upstream. The kernel panics on PV domains because native_smp_cpus_done() is only called for HVM domains.

[Xen-devel] [PATCH resend 07/13] arm: Adding ACPI_IORT in arm Kconfig

From: Manish Jaggi Signed-off-by: Manish Jaggi --- xen/arch/arm/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 2782ee6589..d3fbcbcc6f 100644 --- a/xen/arch/arm/Kconfig +++

  1   2   >