[Xen-devel] [xen-unstable test] 125691: tolerable FAIL - PUSHED

flight 125691 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/125691/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125667

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

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

[Xen-devel] [distros-debian-snapshot test] 75030: regressions - FAIL

flight 75030 distros-debian-snapshot real [real] http://osstest.xensource.com/osstest/logs/75030/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-i386-daily-netboot-pvgrub 10 debian-di-install fail REGR. vs. 75000 Tests

[Xen-devel] [ovmf baseline-only test] 75031: tolerable FAIL

This run is configured for baseline tests only. flight 75031 ovmf real [real] http://osstest.xensource.com/osstest/logs/75031/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75025

[Xen-devel] [PATCH v3 04/25] xen/arm: document dom0less

Add a new document to provide information on how to use dom0less related features and their current limitations. Signed-off-by: Stefano Stabellini --- Changes in v3: - add patch --- docs/misc/arm/dom0less | 47 +++ 1 file changed, 47 insertions(+)

[Xen-devel] [PATCH v3 22/25] xen/arm: Allow vpl011 to be used by DomU

Make vpl011 being able to be used without a userspace component in Dom0. In that case, output is printed to the Xen serial and input is received from the Xen serial one character at a time. Call domain_vpl011_init during construct_domU if vpl011 is enabled. Introduce a new ring struct with only

[Xen-devel] [PATCH v3 18/25] xen/arm: generate a simple device tree for domUs

Introduce functions to generate a basic domU device tree, similar to the existing functions in tools/libxl/libxl_arm.c. Signed-off-by: Stefano Stabellini --- Changes in v3: - remove CONFIG_ACPI for make_chosen_node - remove make_hypervisor_node until all Xen related functionalities (evtchns,

[Xen-devel] [PATCH v3 02/25] xen/arm: move a few DT related defines to public/device_tree_defs.h

Move a few constants defined by libxl_arm.c to xen/include/public/device_tree_defs.h, so that they can be used from Xen and libxl. Prepend GUEST_ to avoid conflicts. Move the DT_IRQ_TYPE* definitions from libxl_arm.c to public/device_tree_defs.h. Use them in Xen where appropriate. Re-define the

[Xen-devel] [PATCH v3 25/25] xen/arm: split domain_build.c

domain_build.c is too large. Move all the ACPI specific device tree generating functions from domain_build.c to acpi/acpi_dt_build.c. Signed-off-by: Stefano Stabellini --- xen/arch/arm/acpi/Makefile| 1 + xen/arch/arm/acpi/acpi_dt_build.c | 591 ++

[Xen-devel] [PATCH v3 24/25] xen/vpl011: buffer out chars when the backend is xen

To avoid mixing the output of different domains on the console, buffer the output chars and print line by line. Unless the domain has input from the serial, in which case we want to print char by char for a smooth user experience. The size of SBSA_UART_OUT_BUF_SIZE is arbitrary. 90 should be

[Xen-devel] [PATCH v3 10/25] xen/arm: don't add duplicate boot modules

Don't add duplicate boot modules (same kind and same start address). Mark kernels and ramdisks of "xen,domain" nodes as BOOTMOD_KERNEL_DOMAIN and BOOTMOD_RAMDISK_DOMAIN respectively, to avoid getting confused in kernel_probe, where we try to guess which is the dom0 kernel and initrd to be

[Xen-devel] [PATCH v3 03/25] xen/arm: extend device tree based multiboot protocol

Extend the existing device tree based multiboot protocol to include information regarding multiple domains to boot. Signed-off-by: Stefano Stabellini --- Changes in v3: - remove "xen,initial-domain" for now - make vpl011 an empty property - memory in KBs Changes in v2: - lower case kernel -

[Xen-devel] [PATCH v3 01/25] xen: allow console_io hypercalls from certain DomUs

Introduce an is_console option to allow certain classes of domUs to use the Xen console. Specifically, it will be used to give console access to all domUs started from Xen from information on device tree. Signed-off-by: Stefano Stabellini CC: andrew.coop...@citrix.com CC:

[Xen-devel] [PATCH v3 16/25] xen/arm: rename allocate_memory to allocate_memory_11

allocate_memory only deals with directly mapped memory. Rename it to allocate_memory_11. Signed-off-by: Stefano Stabellini --- Changes in v3: - add patch --- xen/arch/arm/domain_build.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/domain_build.c

[Xen-devel] [PATCH v3 14/25] xen/arm: introduce construct_domU

Similar to construct_dom0, construct_domU creates a barebone DomU guest. The device tree node passed as argument is compatible "xen,domain", see docs/misc/arm/device-tree/booting.txt. Signed-off-by: Stefano Stabellini --- Changes in v3: - move setting type before allocate_memory - add ifdef

[Xen-devel] [PATCH v3 05/25] xen/arm: do not pass dt_host to make_memory_node and make_hypervisor_node

In order to make make_memory_node and make_hypervisor_node more reusable, do not pass them dt_host. As they only use it to calculate addrcells and sizecells, pass addrcells and sizecells directly. Signed-off-by: Stefano Stabellini --- Changes in v3: - split evtchn_allocate movement to separate

[Xen-devel] [PATCH v3 15/25] xen/arm: rename get_11_allocation_size to get_allocation_size

No functional changes. Signed-off-by: Stefano Stabellini --- Changes in v3: - no change in print messages - do not remove BUG_ON Changes in v2: - new patch --- xen/arch/arm/domain_build.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[Xen-devel] [PATCH v3 00/25] dom0less step1: boot multiple domains from device tree

Hi all, This is first step toward "dom0less" as discussed in the various certifications related threads and discussions. The goal of this series is to enable Xen to boot multiple domains in parallel, in addition to dom0, out of information found on device tree. The device tree based boot

[Xen-devel] [PATCH v3 11/25] xen/arm: probe domU kernels and initrds

Find addresses, sizes on device tree from kernel_probe. Find the cmdline from the bootcmdlines array. Introduce a new boot_module_find_by_addr_and_kind function to match not just on boot module kind, but also by address so that we can support multiple domains. Introduce a

[Xen-devel] [PATCH v3 07/25] xen/arm: rename acpi_make_chosen_node to make_chosen_node

acpi_make_chosen_node is actually generic and can be reused. Rename it to make_chosen_node and make it available to non-ACPI builds. Signed-off-by: Stefano Stabellini --- Removed Julien's ack due to small change below Changes in v3: - retain CONFIG_ACPI not to break bisection for !ACPI build,

[Xen-devel] [PATCH v3 19/25] xen/arm: generate vpl011 node on device tree for domU

Introduce vpl011 support to guests started from Xen: it provides a simple way to print output from a guest, as most guests come with a pl011 driver. It is also able to provide a working console with interrupt support. The UART exposed to the guest is a SBSA compatible UART and not a PL011. SBSA

[Xen-devel] [PATCH v3 17/25] xen/arm: introduce allocate_memory

Introduce an allocate_memory function able to allocate memory for DomUs and map it at the right guest addresses, according to the guest memory map: GUEST_RAM0_BASE and GUEST_RAM1_BASE. Signed-off-by: Stefano Stabellini --- Changes in v3: - new patch --- xen/arch/arm/domain_build.c | 125

[Xen-devel] [PATCH v3 09/25] xen/arm: introduce bootcmdlines

Introduce a new array to store the cmdline of each boot module. It is separate from struct bootmodules. Remove the cmdline field from struct boot_module. This way, kernels and initrds with the same address in memory can share struct bootmodule (important because we want them to be free'd only

[Xen-devel] [PATCH v3 21/25] xen/arm: refactor vpl011_data_avail

Move the code to calculate in_fifo_level and out_fifo_level out of vpl011_data_avail, to the caller. This change will make it possible to reuse vpl011_data_avail with different ring structures in a later patch. Signed-off-by: Stefano Stabellini --- Changes in v3: - remove forward declaration of

[Xen-devel] [PATCH v3 20/25] xen/arm: introduce a union in vpl011

Introduce a union in struct vpl011 to contain the console ring members. A later patch will add another member of the union for the case where the backend is in Xen. Signed-off-by: Stefano Stabellini --- Changes in v3: - rename ring field to dom Changes in v2: - new patch ---

[Xen-devel] [PATCH v3 13/25] xen/arm: introduce create_domUs

Call a new function, "create_domUs", from setup_xen to start DomU VMs. Introduce support for the "xen,domU" compatible node on device tree. Create new DomU VMs based on the information found on device tree under "xen,domU". Calls construct_domU for each domain. Introduce a simple global variable

[Xen-devel] [PATCH v3 06/25] xen/arm: move evtchn_allocate call out of make_hypervisor_node

In the case of domUs, evtchn_irq is allocated by arch_domain_create and set to GUEST_EVTCHN_PPI. To make make_hypervisor_node more reusable, move the call to evtchn_allocate out of make_hypervisor_node, to the dom0 specific caller (handle_node). Signed-off-by: Stefano Stabellini --- Changes in

[Xen-devel] [PATCH v3 23/25] xen: support console_switching between Dom0 and DomUs on ARM

Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the mechanism to allow for switching between Xen, Dom0, and any of the initial DomU created from Xen alongside Dom0 out of information provided via device tree. Rename xen_rx to console_rx to match the new behavior. Clarify existing

[Xen-devel] [PATCH v3 12/25] xen/arm: refactor construct_dom0

Move generic initializations out of construct_dom0 so that they can be reused. Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion. No functional changes in this patch. Signed-off-by: Stefano Stabellini --- Changes in v3: - move setting type before allocate_memory - add ifdef around it

[Xen-devel] [PATCH v3 08/25] xen/arm: increase MAX_MODULES

Xen boot modules need to account not just for Dom0 but also for a few potential DomUs, each of them coming with their own kernel and initrd. Increase MAX_MODULES to 32 to allow for more DomUs. Signed-off-by: Stefano Stabellini Reviewed-by: Doug Goldstein --- xen/include/asm-arm/setup.h | 2 +-

[Xen-devel] [xen-4.11-testing baseline-only test] 75029: tolerable FAIL

This run is configured for baseline tests only. flight 75029 xen-4.11-testing real [real] http://osstest.xensource.com/osstest/logs/75029/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail

[Xen-devel] Networking with MiniOS

Dear All, I am trying to enable networking with MiniOS. I created a daytime server based on daytime.c shipped with MiniOS. The code in daytime.c is copied into stubdom/c/main.c and built with c-stubdom. Server thread is created

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

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

[Xen-devel] [xen-4.9-testing test] 125686: regressions - FAIL

flight 125686 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125686/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248

[Xen-devel] [PATCH] tools/gdbsx: use inttypes.h instead of custom macros

Signed-off-by: Marek Marczykowski-Górecki --- This is on top of "tools/gdbsx: fix 'g' packet response for 64bit guests" patch. --- tools/debugger/gdbsx/gx/gx_local.c | 17 +- tools/debugger/gdbsx/gx/gx_main.c | 5 +-- tools/debugger/gdbsx/xg/xg_public.h | 8 -

[Xen-devel] [PATCH v6 5/7] libxl:xl: add parsing code to parse "libxl_static_sshm" from xl config files

From: Zhongze Liu Author: Zhongze Liu Add the parsing utils for the newly introduced libxl_static_sshm struct to the libxl/libxlu_* family. And add realated parsing code in xl to parse the struct from xl config files. This is for the proposal "Allow setting up shared memory areas between VMs

[Xen-devel] [PATCH v6 7/7] xen/arm: export shared memory regions as reserved-memory on device tree

Shared memory regions need to be advertised to the guest. Fortunately, a device tree binding for special memory regions already exist: reserved-memory. Add a reserved-memory node for each shared memory region, for both masters and slaves. Signed-off-by: Stefano Stabellini ---

[Xen-devel] [PATCH v6 1/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

From: Zhongze Liu Author: Zhongze Liu The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids a Dom0 to map memory pages from one DomU to another, which restricts some useful yet not dangerous use cases -- such as sharing pages among DomU's so that they can do shm-based

[Xen-devel] [PATCH v6 4/7] libxl: support unmapping static shared memory areas during domain destruction

From: Zhongze Liu Author: Zhongze Liu Add libxl__sshm_del to unmap static shared memory areas mapped by libxl__sshm_add during domain creation. The unmapping process is: * For a master: decrease the refcount of the sshm region, if the refcount reaches 0, cleanup the whole sshm path. * For

[Xen-devel] [PATCH v6 2/7] libxl: introduce a new structure to represent static shared memory regions

From: Zhongze Liu Author: Zhongze Liu Add a new structure to the IDL family to represent static shared memory regions as proposed in the proposal "Allow setting up shared memory areas between VMs from xl config file" (see [1]). And deleted some trailing white spaces. [1]

[Xen-devel] [PATCH v6 6/7] docs: documentation about static shared memory regions

From: Zhongze Liu Author: Zhongze Liu Add docs to document the motivation, usage, use cases and other relevant information about the static shared memory feature. This is for the proposal "Allow setting up shared memory areas between VMs from xl config file". See:

[Xen-devel] [PATCH v6 3/7] libxl: support mapping static shared memory areas during domain creation

From: Zhongze Liu Author: Zhongze Liu Add libxl__sshm_add to map shared pages from one DomU to another, The mapping process involves the following steps: * Set defaults and check for further errors in the static_shm configs: overlapping areas, invalid ranges, duplicated master domain,

[Xen-devel] [PATCH v6 0/7] Allow setting up shared memory areas between VMs from xl config files

Hi, This series implements a new xl config entry. Users can use the new config entry to statically setup shared memory areas among VMs that don't have grant table support so that they could communicate with each other through the static shared memory areas. It was originally developed by

Re: [Xen-devel] Xen 4.12 Development Update

> On Jul 27, 2018, at 12:19, Juergen Gross wrote: > > This email only tracks big items for xen.git tree. Please reply for items you > would like to see in 4.12 so that people have an idea what is going on and > prioritise accordingly. Two additional items: 1. Linux stub domains, series posted

[Xen-devel] [xen-4.7-testing test] 125685: regressions - FAIL

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

Re: [Xen-devel] [PATCH] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU

On 07/31/2018 08:19 PM, Tamas K Lengyel wrote: > On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote: >> I'd like you to outline in the description how you mean an external >> agent to coordinate the use of this GFN with the guest (and in >> particular without in-guest agent). > > Using #VE

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

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

Re: [Xen-devel] [PATCH] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU

On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote: > > >>> On 25.07.18 at 13:49, wrote: > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -4467,6 +4467,30 @@ static int hvmop_get_param( > > return rc; > > } > > > > +/* > > + * Find the struct vcpu given a dom_id and

Re: [Xen-devel] [PATCH][next] xen/gntdev: don't dereference a null gntdev_dmabuf on allocation failure

On 07/31/2018 10:02 AM, Colin King wrote: > From: Colin Ian King > > Currently when the allocation of gntdev_dmabuf fails, the error exit > path will call dmabuf_imp_free_storage and causes a null pointer > dereference on gntdev_dmabuf. Fix this by adding an error exit path > that won't free

Re: [Xen-devel] [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU

On 07/19/2018 05:39 PM, Waiman Long wrote: > On a VM with only 1 vCPU, the locking fast paths will always be > successful. In this case, there is no need to use the the PV qspinlock > code which has higher overhead on the unlock side than the native > qspinlock code. > > The xen_pvspin veriable is

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > This work is in response to my previous attempt to introduce Xen/DRM > zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based > frontends/backends. There is also an existing hyper_dmabuf

[Xen-devel] [xen-4.6-testing test] 125683: regressions - FAIL

flight 125683 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125683/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 6 xen-install fail REGR. vs. 124881 Regressions

Re: [Xen-devel] [PATCH] tools/gdbsx: fix 'g' packet response for 64bit guests

On 31/07/18 17:10, Marek Marczykowski-Górecki wrote: > On Tue, Jul 31, 2018 at 10:00:24AM +0100, Wei Liu wrote: >> On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote: >>> --- a/tools/debugger/gdbsx/gx/gx_local.c >>> +++ b/tools/debugger/gdbsx/gx/gx_local.c >>> @@ -45,8

Re: [Xen-devel] [PATCH] tools/gdbsx: fix 'g' packet response for 64bit guests

On Tue, Jul 31, 2018 at 06:10:07PM +0200, Marek Marczykowski-Górecki wrote: > On Tue, Jul 31, 2018 at 10:00:24AM +0100, Wei Liu wrote: > > On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote: > > > --- a/tools/debugger/gdbsx/gx/gx_local.c > > > +++

Re: [Xen-devel] [PATCH v2] xenconsole: add option to avoid escape sequences in log

On Tue, Jul 31, 2018 at 10:10:10AM +0100, Wei Liu wrote: > On Tue, Jul 31, 2018 at 05:15:32AM +0200, Marek Marczykowski-Górecki wrote: > > Add --replace-escape option to xenconsoled, which replaces ESC with > > '.' in console output written to log file. This makes it slightly safer > > to do tail

Re: [Xen-devel] [PATCH v8 00/11] arm: more kconfig configurability and small default configs

On Tue, 31 Jul 2018, Julien Grall wrote: > On 30/07/18 18:48, Stefano Stabellini wrote: > > Hi all, > > Hi Stefano, > > > > > This patch series is the first step toward building a small certifiable > > Xen hypervisor for ARM boards. > > > > The series makes a few changes to allow disabling

Re: [Xen-devel] [PATCH] tools/gdbsx: fix 'g' packet response for 64bit guests

On Tue, Jul 31, 2018 at 10:00:24AM +0100, Wei Liu wrote: > On Tue, Jul 31, 2018 at 04:30:42AM +0200, Marek Marczykowski-Górecki wrote: > > --- a/tools/debugger/gdbsx/gx/gx_local.c > > +++ b/tools/debugger/gdbsx/gx/gx_local.c > > @@ -45,8 +45,8 @@ prnt_32regs(struct xg_gdb_regs32 *r32p) > > static

Re: [Xen-devel] [PATCH] tools/gdbsx: fix 'g' packet response for 64bit guests

On Tue, Jul 31, 2018 at 02:01:39AM -0600, Jan Beulich wrote: > >>> On 31.07.18 at 04:30, wrote: > > Marek, > > looks like all of the patches you've sent early this morning local time > here came through twice on xen-devel: Would you please avoid > having xen-devel on both the To and the Cc

Re: [Xen-devel] [PATCH 4/4] x86/iommu: add PVH support to the inclusive options

>>> On 31.07.18 at 17:27, wrote: > On Tue, Jul 31, 2018 at 05:15:22PM +0200, Roger Pau Monné wrote: >> On Tue, Jul 31, 2018 at 08:52:14AM -0600, Jan Beulich wrote: >> > >>> On 27.07.18 at 17:31, wrote: >> > > --- a/xen/drivers/passthrough/x86/iommu.c >> > > +++

Re: [Xen-devel] [PATCH 4/4] x86/iommu: add PVH support to the inclusive options

>>> On 31.07.18 at 17:15, wrote: > On Tue, Jul 31, 2018 at 08:52:14AM -0600, Jan Beulich wrote: >> >>> On 27.07.18 at 17:31, wrote: >> > +/* ... or the PCIe MCFG regions. */ >> > +for ( i = 0; i < pci_mmcfg_config_num; i++ ) >> > +{ >> > +unsigned long addr =

Re: [Xen-devel] [PATCH 2/4] iommu: generalize iommu_inclusive_mapping

On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote: > >>> On 27.07.18 at 17:31, wrote: > > Introduce a new iommu=inclusive generic option that supersedes > > iommu_inclusive_mapping. This should be a non-functional change on > > Intel hardware, while AMD hardware will gain the same

Re: [Xen-devel] [PATCH 4/4] x86/iommu: add PVH support to the inclusive options

On Tue, Jul 31, 2018 at 05:15:22PM +0200, Roger Pau Monné wrote: > On Tue, Jul 31, 2018 at 08:52:14AM -0600, Jan Beulich wrote: > > >>> On 27.07.18 at 17:31, wrote: > > > --- a/xen/drivers/passthrough/x86/iommu.c > > > +++ b/xen/drivers/passthrough/x86/iommu.c > > > @@ -20,6 +20,8 @@ > > >

Re: [Xen-devel] [PATCH 4/4] x86/iommu: add PVH support to the inclusive options

On Tue, Jul 31, 2018 at 08:52:14AM -0600, Jan Beulich wrote: > >>> On 27.07.18 at 17:31, wrote: > > Several people have reported hardware issues (malfunctioning USB > > controllers) due to iommu page faults. Those faults are caused by > > missing RMRR (VTd) or IRVS (AMD-Vi) entries in the ACPI

Re: [Xen-devel] [PATCH v3] hvm/altp2m: Clarify the proper way to extend the altp2m interface

On Tue, Jul 31, 2018 at 04:03:31PM +0100, George Dunlap wrote: > diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h > index 2ec2e7c80f..daa28a86be 100644 > --- a/xen/include/public/hvm/params.h > +++ b/xen/include/public/hvm/params.h > @@ -239,6 +239,11 @@ > * mixed:

Re: [Xen-devel] [PATCH v3] hvm/altp2m: Clarify the proper way to extend the altp2m interface

On Tue, Jul 31, 2018 at 04:03:31PM +0100, George Dunlap wrote: [...] > > Reviewed-by: Razvan Cojocaru > Signed-off-by: George Dunlap LGTM, FWIW: Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] [PATCH v3] hvm/altp2m: Clarify the proper way to extend the altp2m interface

The altp2m functionality was originally envisioned to be used in several different configurations, one of which was a single in-guest agent that had full operational control of altp2m. This required the single hypercall to be an HVMOP rather than a DOMCTL, since HVM guests are not allowed to make

Re: [Xen-devel] [PATCH 4/4] x86/iommu: add PVH support to the inclusive options

>>> On 27.07.18 at 17:31, wrote: > Several people have reported hardware issues (malfunctioning USB > controllers) due to iommu page faults. Those faults are caused by > missing RMRR (VTd) or IRVS (AMD-Vi) entries in the ACPI tables. Those > can be worked around on VTd hardware by manually adding

Re: [Xen-devel] [PATCH 2/4] iommu: generalize iommu_inclusive_mapping

>>> On 27.07.18 at 17:31, wrote: > Introduce a new iommu=inclusive generic option that supersedes > iommu_inclusive_mapping. This should be a non-functional change on > Intel hardware, while AMD hardware will gain the same functionality of > mapping almost everything below the 4GB boundary. So

Re: [Xen-devel] [PATCH v14 10/11] x86/hvm: Remove redundant save functions

>>> On 31.07.18 at 15:32, wrote: > On Ma, 2018-07-31 at 07:24 -0600, Jan Beulich wrote: >> > > > On 25.07.18 at 14:14, wrote: >> > --- a/xen/arch/x86/hvm/hpet.c >> > +++ b/xen/arch/x86/hvm/hpet.c >> > @@ -516,8 +516,9 @@ static const struct hvm_mmio_ops hpet_mmio_ops >> > = { >> > }; >> > >>

[Xen-devel] [linux-linus test] 125676: regressions - FAIL

flight 125676 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/125676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125648

Re: [Xen-devel] [PATCH v14 08/11] x86/hvm: Add handler for save_one funcs

>>> On 31.07.18 at 15:45, wrote: > On Ma, 2018-07-31 at 07:32 -0600, Jan Beulich wrote: >> > > > On 31.07.18 at 14:55, wrote: >> > On Ma, 2018-07-31 at 06:34 -0600, Jan Beulich wrote: >> > > > > > On 25.07.18 at 14:14, wrote: >> > > > @@ -114,12 +117,13 @@ void hvm_register_savevm(uint16_t >> >

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

flight 125679 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125679/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 18 guest-localmigrate/x10 fail REGR. vs. 125624 Tests which

[Xen-devel] [PATCH][next] xen/gntdev: don't dereference a null gntdev_dmabuf on allocation failure

From: Colin Ian King Currently when the allocation of gntdev_dmabuf fails, the error exit path will call dmabuf_imp_free_storage and causes a null pointer dereference on gntdev_dmabuf. Fix this by adding an error exit path that won't free gntdev_dmabuf. Detected by CoverityScan, CID#1472124

Re: [Xen-devel] [PATCH v14 08/11] x86/hvm: Add handler for save_one funcs

On Ma, 2018-07-31 at 07:32 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 31.07.18 at 14:55, wrote: > > On Ma, 2018-07-31 at 06:34 -0600, Jan Beulich wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 25.07.18 at 14:14, wrote: > > > > --- a/xen/arch/x86/hvm/vlapic.c > > > >

Re: [Xen-devel] [PATCH v14 08/11] x86/hvm: Add handler for save_one funcs

>>> On 31.07.18 at 14:55, wrote: > On Ma, 2018-07-31 at 06:34 -0600, Jan Beulich wrote: >> > > > On 25.07.18 at 14:14, wrote: >> > --- a/xen/arch/x86/hvm/vlapic.c >> > +++ b/xen/arch/x86/hvm/vlapic.c >> > @@ -1576,9 +1576,9 @@ static int lapic_load_regs(struct domain *d, >> >

Re: [Xen-devel] [PATCH v14 10/11] x86/hvm: Remove redundant save functions

On Ma, 2018-07-31 at 07:24 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 25.07.18 at 14:14, wrote: > > --- a/xen/arch/x86/hvm/hpet.c > > +++ b/xen/arch/x86/hvm/hpet.c > > @@ -516,8 +516,9 @@ static const struct hvm_mmio_ops hpet_mmio_ops > > = { > >  }; > >   > >   > > -static int

Re: [Xen-devel] [PATCH v14 10/11] x86/hvm: Remove redundant save functions

>>> On 25.07.18 at 14:14, wrote: > --- a/xen/arch/x86/hvm/hpet.c > +++ b/xen/arch/x86/hvm/hpet.c > @@ -516,8 +516,9 @@ static const struct hvm_mmio_ops hpet_mmio_ops = { > }; > > > -static int hpet_save(struct domain *d, hvm_domain_context_t *h) > +static int hpet_save(struct vcpu *vcpu,

Re: [Xen-devel] [PATCH v14 09/11] x86/domctl: Don't pause the whole domain if only getting vcpu state

>>> On 25.07.18 at 14:14, wrote: > This patch is focused on moving the for loop to the caller so > now we can save info for a single vcpu instance with the save_one > handlers. > > Signed-off-by: Alexandru Isaila First of all I'd appreciate if this patch was last in the series, after all

Re: [Xen-devel] [PATCH v14 08/11] x86/hvm: Add handler for save_one funcs

On Ma, 2018-07-31 at 06:34 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 25.07.18 at 14:14, wrote: > > --- a/xen/arch/x86/hvm/save.c > > +++ b/xen/arch/x86/hvm/save.c > > @@ -85,16 +85,18 @@ int arch_hvm_load(struct domain *d, struct > > hvm_save_header *hdr) > >  /* List of handlers

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

flight 125677 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125677/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail REGR. vs. 124988 Tests which

Re: [Xen-devel] [PATCH v14 08/11] x86/hvm: Add handler for save_one funcs

>>> On 25.07.18 at 14:14, wrote: > --- a/xen/arch/x86/hvm/save.c > +++ b/xen/arch/x86/hvm/save.c > @@ -85,16 +85,18 @@ int arch_hvm_load(struct domain *d, struct > hvm_save_header *hdr) > /* List of handlers for various HVM save and restore types */ > static struct { > hvm_save_handler

Re: [Xen-devel] [PATCH v14 07/11] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func

>>> On 25.07.18 at 14:14, wrote: > --- a/xen/arch/x86/hvm/viridian.c > +++ b/xen/arch/x86/hvm/viridian.c > @@ -1026,24 +1026,32 @@ static int viridian_load_domain_ctxt(struct domain > *d, hvm_domain_context_t *h) > HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt, >

Re: [Xen-devel] [PATCH v14 06/11] x86/hvm: Introduce hvm_save_mtrr_msr_one func

>>> On 25.07.18 at 14:14, wrote: > This is used to save data from a single instance. > > Signed-off-by: Alexandru Isaila > > --- > Changes since v11: > - hvm_save_mtrr_msr() now returns err from hvm_save_mtrr_msr_one(). > > Note: This patch is based on Roger Pau Monne's series[1] > ---

Re: [Xen-devel] [PATCH v14 05/11] x86/hvm: Introduce hvm_save_cpu_msrs_one func

>>> On 25.07.18 at 14:14, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -1366,69 +1366,80 @@ static const uint32_t msrs_to_send[] = { > }; > static unsigned int __read_mostly msr_count_max = ARRAY_SIZE(msrs_to_send); > > -static int hvm_save_cpu_msrs(struct domain

Re: [Xen-devel] [PATCH v14 01/11] x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func

>>> On 31.07.18 at 13:56, wrote: On 25.07.18 at 14:14, wrote: >> --- a/xen/arch/x86/cpu/mcheck/vmce.c >> +++ b/xen/arch/x86/cpu/mcheck/vmce.c >> @@ -349,6 +349,18 @@ int vmce_wrmsr(uint32_t msr, uint64_t val) >> return ret; >> } >> >> +static int vmce_save_vcpu_ctxt_one(struct vcpu

Re: [Xen-devel] [PATCH v14 04/11] x86/hvm: Introduce hvm_save_cpu_xsave_states_one

>>> On 25.07.18 at 14:14, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -1188,33 +1188,45 @@ HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, > hvm_load_cpu_ctxt, > save_area) + \ >

Re: [Xen-devel] [PATCH v14 03/11] x86/hvm: Introduce hvm_save_cpu_ctxt_one func

>>> On 25.07.18 at 14:14, wrote: > This is used to save data from a single instance. > > Signed-off-by: Alexandru Isaila > > --- > Changes since V12: > - Changed memset to {} init. > --- > xen/arch/x86/hvm/hvm.c | 214 > + > 1 file

Re: [Xen-devel] [PATCH v14 01/11] x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func

>>> On 25.07.18 at 14:14, wrote: > --- a/xen/arch/x86/cpu/mcheck/vmce.c > +++ b/xen/arch/x86/cpu/mcheck/vmce.c > @@ -349,6 +349,18 @@ int vmce_wrmsr(uint32_t msr, uint64_t val) > return ret; > } > > +static int vmce_save_vcpu_ctxt_one(struct vcpu *v, hvm_domain_context_t *h) Afaict v can

Re: [Xen-devel] [PATCH] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU

>>> On 25.07.18 at 13:49, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -4467,6 +4467,30 @@ static int hvmop_get_param( > return rc; > } > > +/* > + * Find the struct vcpu given a dom_id and vcpu_id. > + * Return NULL if not found. > + */ > +static struct vcpu

Re: [Xen-devel] [PATCH v4 3/3] x86/altp2m: Add a hvmop for querying the suppress #VE bit

>>> On 25.07.18 at 13:18, wrote: > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -38,7 +38,7 @@ struct xen_hvm_param { > typedef struct xen_hvm_param xen_hvm_param_t; > DEFINE_XEN_GUEST_HANDLE(xen_hvm_param_t); > > -struct xen_hvm_altp2m_set_suppress_ve {

Re: [Xen-devel] [PATCH v3] x86/altp2m: Add a subop for obtaining the mem access of a page

>>> On 25.07.18 at 13:16, wrote: > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -234,7 +234,7 @@ struct xen_hvm_altp2m_view { > typedef struct xen_hvm_altp2m_view xen_hvm_altp2m_view_t; > DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_view_t); > > -struct

[Xen-devel] [linux-next test] 125672: regressions - FAIL

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

Re: [Xen-devel] [PATCH v8 00/11] arm: more kconfig configurability and small default configs

On 30/07/18 18:48, Stefano Stabellini wrote: Hi all, Hi Stefano, This patch series is the first step toward building a small certifiable Xen hypervisor for ARM boards. The series makes a few changes to allow disabling more kconfig options: most of them already exist but cannot be

Re: [Xen-devel] [PATCH 3/3] x86/spec-ctrl: Add support for modifying SSBD AMD VIA LS_CFG MSR

>>> On 20.07.18 at 16:57, wrote: > --- a/xen/arch/x86/cpu/amd.c > +++ b/xen/arch/x86/cpu/amd.c > @@ -607,16 +607,10 @@ static void init_amd(struct cpuinfo_x86 *c) > case 0x17: bit = 10; break; > } > > - if (bit >= 0) > -

[Xen-devel] [xen-unstable baseline-only test] 75028: regressions - FAIL

This run is configured for baseline tests only. flight 75028 xen-unstable real [real] http://osstest.xensource.com/osstest/logs/75028/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-1 63 xtf/test-hvm64-xsa-204

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

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

Re: [Xen-devel] [PATCH v8 08/11] arm: add ALL_PLAT, QEMU, Rcar3 and MPSoC configs

Hi Stefano, On 30/07/18 18:48, Stefano Stabellini wrote: Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3, MPSOC and ALL_PLAT. They enable the required options for their hardware platform. ALL_PLAT enables all available platforms and it's the default. It doesn't

Re: [Xen-devel] [PATCH v8 02/11] arm: make it possible to disable HAS_GICV3

Hi Jan, On 31/07/18 09:04, Jan Beulich wrote: On 30.07.18 at 19:48, wrote: Today it is a silent option. This patch adds a one line description and makes it optional. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall CC: george.dun...@eu.citrix.com CC: ian.jack...@eu.citrix.com CC:

Re: [Xen-devel] [PATCH 1/3] x86/spec-ctrl: add AMD SSBD LS_CFG in init print

>>> On 20.07.18 at 16:57, wrote: > Edit the initialization code for AMD's SSBD via the LS_CFG MSR and > enable it to pass the status to the initial spec-ctrl print_details at > boot. > > Signed-off-by: Brian Woods > --- > xen/arch/x86/cpu/amd.c| 13 ++--- >

Re: [Xen-devel] [PATCH 2/3] x86/spec-ctrl: Add defines and variables for AMD SSBD support

>>> On 20.07.18 at 16:57, wrote: > In preparation for adding switchable SSBD, add some defines and > variables. > > Signed-off-by: Brian Woods Whether these additions fit the purpose can only be told when seeing their use. Please fold this into the patch using these. Jan

  1   2   >