Re: [Xen-devel] Regarding hdmi sharing in xen

> > Dear Andrii Anisov, Thank you for the reply. We are using R-Car H3 salvator X. > It really depends on the setup you need. Our plan is to run Linux as Dom0 and Android as DomU. The Linux portion will be having 1 HDMI display and the Android porion will be having 1 HDMI. Can we share the DU

Re: [Xen-devel] [PATCH] xen-blkfront: fix mq start/stop race

Hi Roger, On 06/23/2017 08:57 PM, Roger Pau Monné wrote: > On Thu, Jun 22, 2017 at 09:36:52AM +0800, Junxiao Bi wrote: >> When ring buf full, hw queue will be stopped. While blkif interrupt consume >> request and make free space in ring buf, hw queue will be started again. >> But since start

Re: [Xen-devel] [RFC 21/22] x86/module: Add support for mcmodel large and PLTs

On Tue, Jul 18, 2017 at 9:35 PM, H. Peter Anvin wrote: > On 07/18/17 15:33, Thomas Garnier wrote: >> With PIE support and KASLR extended range, the modules may be further >> away from the kernel than before breaking mcmodel=kernel expectations. >> >> Add an option to build modules

[Xen-devel] [RFC PATCH] tools/libxl : add struct and parsing utils for the 'static_shm' xl config entry

Add a new struct libxl_static_shm in the libxl IDL for the proposed new xl config entry 'static_shm' (see [1]), which allow the user to set up shared memory areas among several VMs for communication. Add related parsing code to the libxl/libxlu_* family and xl/xl_parse.c [1]: [RFC v3]Proposal to

Re: [Xen-devel] [RFC 16/22] x86/percpu: Adapt percpu for PIE support

On Tue, Jul 18, 2017 at 6:33 PM, Thomas Garnier wrote: > Perpcu uses a clever design where the .percu ELF section has a virtual > address of zero and the relocation code avoid relocating specific > symbols. It makes the code simple and easily adaptable with or without > SMP

Re: [Xen-devel] [RFC 06/22] kvm: Adapt assembly for PIE support

On Tue, Jul 18, 2017 at 6:33 PM, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. The new __ASM_GET_PTR_PRE macro is used to > get the address of a symbol on both 32 and 64-bit with PIE support.

Re: [Xen-devel] [RFC 21/22] x86/module: Add support for mcmodel large and PLTs

On 07/18/17 15:33, Thomas Garnier wrote: > With PIE support and KASLR extended range, the modules may be further > away from the kernel than before breaking mcmodel=kernel expectations. > > Add an option to build modules with mcmodel=large. The modules generated > code will make no assumptions on

Re: [Xen-devel] [RFC v3]Proposal to allow setting up shared memory areas between VMs from xl config file

Forget to restrict the possible values of begin/end. 2017-07-19 2:30 GMT+08:00 Zhongze Liu : > > 1. Motivation and Description > > Virtual machines use grant table

Re: [Xen-devel] [PATCH] kbdif: Define "feature-raw-pointer" and "request-raw-pointer"

On Tue, Jul 18, 2017 at 03:29:14PM -0700, Stefano Stabellini wrote: > On Mon, 3 Jul 2017, Stefano Stabellini wrote: > > On Mon, 3 Jul 2017, Owen Smith wrote: > > > Backends set "feature-raw-pointer" if its capable of reporting > > > absolute positions without scaling the coordinates to screen > >

[Xen-devel] [xen-unstable-smoke test] 111993: tolerable trouble: broken/pass - PUSHED

flight 111993 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/111993/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13

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

flight 111972 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/111972/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 110515

Re: [Xen-devel] [PATCH 15/15] xen: tools: expose EPC in ACPI table

On 7/18/2017 10:21 PM, Roger Pau Monné wrote: On Tue, Jul 18, 2017 at 08:36:15PM +1200, Huang, Kai wrote: On 7/17/2017 10:54 PM, Roger Pau Monné wrote: On Sun, Jul 09, 2017 at 08:16:05PM +1200, Kai Huang wrote: On physical machine EPC is exposed in ACPI table via "INT0E0C". Although EPC

Re: [Xen-devel] [PATCH 01/15] xen: x86: expose SGX to HVM domain in CPU featureset

On 7/18/2017 10:12 PM, Andrew Cooper wrote: On 09/07/17 09:04, Kai Huang wrote: Expose SGX in CPU featureset for HVM domain. SGX will not be supported for PV domain, as ENCLS (which SGX driver in guest essentially runs) must run in ring 0, while PV kernel runs in ring 3. Theoretically we can

[Xen-devel] [RFC 08/22] 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] [RFC 03/22] 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] [RFC 18/22] x86/relocs: Handle DYN relocations for PIE support

Change the relocation tool to correctly handle DYN/PIE kernel where the relocation table does not reference symbols and percpu support is not needed. Also add support for R_X86_64_RELATIVE relocations that can be handled like a 64-bit relocation due to the usage of -Bsymbolic. Position

[Xen-devel] [RFC 20/22] 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] [RFC 14/22] 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] [RFC 09/22] x86: pm-trace - Adapt assembly for PIE support

Change assembly to use the new _ASM_GET_PTR 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] [RFC 01/22] 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] [RFC 13/22] 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] [RFC 19/22] x86/pie: Add option to build the kernel as PIE for x86_64

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 -2G limit

[Xen-devel] [RFC 21/22] x86/module: Add support for mcmodel large and PLTs

With PIE support and KASLR extended range, the modules may be further away from the kernel than before breaking mcmodel=kernel expectations. Add an option to build modules with mcmodel=large. The modules generated code will make no assumptions on placement in memory. Despite this option, modules

[Xen-devel] [RFC 12/22] 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] x86: PIE support and option to extend KASLR randomization

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel

[Xen-devel] [RFC 22/22] 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] [RFC 16/22] x86/percpu: Adapt percpu for PIE support

Perpcu uses a clever design where the .percu ELF section has a virtual address of zero and the relocation code avoid relocating specific symbols. It makes the code simple and easily adaptable with or without SMP support. This design is incompatible with PIE because generated code always try to

[Xen-devel] [RFC 06/22] 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_GET_PTR_PRE 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] [RFC 04/22] x86: Add macro to get symbol address for PIE support

Add a new _ASM_GET_PTR 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 | 13 + 1 file changed, 13 insertions(+) diff

[Xen-devel] [RFC 05/22] xen: Adapt assembly for PIE support

Change the assembly code to use the new _ASM_GET_PTR macro which get a symbol reference while being PIE compatible. Modify the RELOC macro that was using an assignment generating a non-relative reference. Position Independent Executable (PIE) support will allow to extended the KASLR randomization

[Xen-devel] [RFC 11/22] 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] [RFC 10/22] x86/CPU: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Use the new _ASM_GET_PTR macro instead of the 'mov $symbol, %dst' construct to not have an absolute reference. Position Independent Executable (PIE) support will allow to extended the KASLR

[Xen-devel] [RFC 17/22] 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. Signed-off-by: Thomas Garnier --- arch/x86/boot/boot.h | 2 +-

[Xen-devel] [RFC 07/22] 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] [RFC 02/22] 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

[Xen-devel] [RFC 15/22] x86/boot/64: Use _text in a global for PIE support

By default PIE generated code create only relative references so _text points to the temporary virtual address. Instead use a global variable so the relocation is done as expected. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G

Re: [Xen-devel] [PATCH] kbdif: Define "feature-raw-pointer" and "request-raw-pointer"

On Mon, 3 Jul 2017, Stefano Stabellini wrote: > On Mon, 3 Jul 2017, Owen Smith wrote: > > Backends set "feature-raw-pointer" if its capable of reporting > > absolute positions without scaling the coordinates to screen > > size. This should be set during the backend init. > > Frontends set

[Xen-devel] [PULL for-2.10 6/7] xen/mapcache: introduce xen_replace_cache_entry()

From: Igor Druzhinin This new call is trying to update a requested map cache entry according to the changes in the physmap. The call is searching for the entry, unmaps it and maps again at the same place using a new guest address. If the mapping is dummy this call will

[Xen-devel] [PULL for-2.10 3/7] xen-platform: separate unplugging of NVMe disks

Commit 090fa1c8 "add support for unplugging NVMe disks..." extended the existing disk unplug flag to cover NVMe disks as well as IDE and SCSI. The recent thread on the xen-devel mailing list [1] has highlighted that this is not desirable behaviour: PV frontends should be able to distinguish NVMe

[Xen-devel] [PULL for-2.10 4/7] xen: move physmap saving into a separate function

From: Igor Druzhinin Non-functional change. Signed-off-by: Igor Druzhinin Reviewed-by: Stefano Stabellini Reviewed-by: Paul Durrant --- hw/i386/xen/xen-hvm.c | 57

[Xen-devel] [PULL for-2.10 1/7] hw/xen: Set emu_mask for igd_opregion register

From: Xiong Zhang In igd passthrough environment, guest could only access opregion at the first bootup time. Once guest shutdown, later guest couldn't access opregion anymore. This is because qemu set emulated guest opregion base address to host register. Later guest get

[Xen-devel] [PULL for-2.10 2/7] xen_pt_msi.c: Check for xen_host_pci_get_* failures in xen_pt_msix_init()

From: Peter Maydell Check the return status of the xen_host_pci_get_* functions we call in xen_pt_msix_init(), and fail device init if the reads failed rather than ploughing ahead. (Spotted by Coverity: CID 777338.) Signed-off-by: Peter Maydell

[Xen-devel] [PULL for-2.10 5/7] xen/mapcache: add an ability to create dummy mappings

From: Igor Druzhinin Dummys are simple anonymous mappings that are placed instead of regular foreign mappings in certain situations when we need to postpone the actual mapping but still have to give a memory region to QEMU to play with. This is planned to be used for

[Xen-devel] [PULL for-2.10 7/7] xen: don't use xenstore to save/restore physmap anymore

From: Igor Druzhinin If we have a system with xenforeignmemory_map2() implemented we don't need to save/restore physmap on suspend/restore anymore. In case we resume a VM without physmap - try to recreate the physmap during memory region restore phase and remap map

[Xen-devel] [PULL for-2.0 0/7] please pull xen-20170718-tag

-20170718-tag for you to fetch changes up to 331b5189d756d431b1d18ae7097527ba3d3ea809: xen: don't use xenstore to save/restore physmap anymore (2017-07-18 14:16:52 -0700) Xen 2017/07/18

Re: [Xen-devel] [PATCH] xen-mapcache: Fix the bug when overlapping emulated DMA operations may cause inconsistency in guest memory mappings

On Tue, 11 Jul 2017, Alexey G wrote: > Under certain circumstances normal xen-mapcache functioning may be broken > by guest's actions. This may lead to either QEMU performing exit() due to > a caught bad pointer (and with QEMU process gone the guest domain simply > appears hung afterwards) or

Re: [Xen-devel] [PATCH v3 4/4] xen: don't use xenstore to save/restore physmap anymore

On Mon, 10 Jul 2017, Igor Druzhinin wrote: > If we have a system with xenforeignmemory_map2() implemented > we don't need to save/restore physmap on suspend/restore > anymore. In case we resume a VM without physmap - try to > recreate the physmap during memory region restore phase and > remap map

Re: [Xen-devel] [PATCH v3 3/4] xen/mapcache: introduce xen_replace_cache_entry()

On Mon, 10 Jul 2017, Igor Druzhinin wrote: > This new call is trying to update a requested map cache entry > according to the changes in the physmap. The call is searching > for the entry, unmaps it and maps again at the same place using > a new guest address. If the mapping is dummy this call

Re: [Xen-devel] [PATCH RFC] tools: Drop xc_cpuid_check() and bindings

On Mon, Jul 17, 2017 at 01:54:19PM +, Christian Lindig wrote: > > > On 17. Jul 2017, at 13:38, Andrew Cooper wrote: > > > > It turns out that Xapi has a library function using it, but that > > function is dead so can be removed. > > I am fine with the removal of

Re: [Xen-devel] [PATCH 22/25 v6] xen/arm: vpl011: Add support for vuart console in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch finally adds the support for vuart console. It adds > two new fields in the console initialization: > > - optional > - prefer_gnttab > > optional flag tells whether the console is optional. > > prefer_gnttab tells whether the ring buffer

Re: [Xen-devel] [PATCH 21/25 v6] xen/arm: vpl011: Add support for multiple consoles in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch adds the support for multiple consoles and introduces the iterator > functions to operate on multiple consoles. > > This patch is in preparation to support a new vuart console. > > Signed-off-by: Bhupinder Thakur

Re: [Xen-devel] [PATCH 20/25 v6] xen/arm: vpl011: Add a new console_close_evtchn function in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch introduces a console_close_evtchn console_cleanup function. This > function > closes the console event channel. > > Signed-off-by: Bhupinder Thakur Reviewed-by: Stefano Stabellini

Re: [Xen-devel] [PATCH 19/25 v6] xen/arm: vpl011: Add a new console_open_log function in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch introduces a console_open_log console_cleanup function. This > function > opens the console log file. > > Signed-off-by: Bhupinder Thakur > --- > CC: Ian Jackson > CC: Wei Liu

Re: [Xen-devel] [PATCH 18/25 v6] xen/arm: vpl011: Add a new console_cleanup function in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch introduces a new console_cleanup function. This function > frees up the console resources. > > Signed-off-by: Bhupinder Thakur > --- > CC: Ian Jackson > CC: Wei Liu

Re: [Xen-devel] [PATCH 17/25 v6] xen/arm: vpl011: Add a new handle_console_tty function in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch introduces a new handle_console_tty function. This function > performs read/write from/to console tty. > > Signed-off-by: Bhupinder Thakur Reviewed-by: Stefano Stabellini > --- >

Re: [Xen-devel] [PATCH 16/25 v6] xen/arm: vpl011: Add a new handle_console_ring function in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch introduces a new handle_console_ring function. This function > reads the data from the ring buffer on receiving an event. > > Signed-off-by: Bhupinder Thakur Reviewed-by: Stefano Stabellini

Re: [Xen-devel] [PATCH 14/25 v6] xen/arm: vpl011: Add a new add_console_tty_fd function in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch introduces a new add_console_tty_fd function. This function > adds the tty fd to the list of polled fds. > > Signed-off-by: Bhupinder Thakur Reviewed-by: Stefano Stabellini > --- >

Re: [Xen-devel] [PATCH 12/25 v6] xen/arm: vpl011: Add a new buffer_available function in xenconsole

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > This patch introduces a new buffer_available function to check if > more data is allowed to be buffered. > > Signed-off-by: Bhupinder Thakur Reviewed-by: Stefano Stabellini > --- > CC: Ian

Re: [Xen-devel] [PATCH 06/25 v6] xen/arm: vpl011: Add a new domctl API to initialize vpl011

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > Add a new domctl API to initialize vpl011. It takes the GFN and console > backend domid as input and returns an event channel to be used for > sending and receiving events from Xen. > > Xen will communicate with xenconsole using GFN as the ring

Re: [Xen-devel] [PATCH 02/25 v6] xen/arm: vpl011: Add SBSA UART emulation in Xen

On Mon, 17 Jul 2017, Bhupinder Thakur wrote: > Add emulation code to emulate read/write access to pl011 registers > and pl011 interrupts: > > - Emulate DR read/write by reading and writing from/to the IN > and OUT ring buffers and raising an event to the backend when > there is

Re: [Xen-devel] [PATCH XTF v2] Implement pv_read

On 18/07/17 15:53, Felix Schmoll wrote: > Implement reading from PV console. Making use of polling. > > Signed-off-by: Felix Schmoll > --- > common/console.c | 22 ++ > include/xtf/console.h | 2 ++ > 2 files changed, 24 insertions(+) > >

[Xen-devel] [xtf test] 111982: all pass - PUSHED

flight 111982 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111982/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 4b3fe14e291109d6a1fc140c039e8a638672070a baseline version: xtf

[Xen-devel] [RFC v3]Proposal to allow setting up shared memory areas between VMs from xl config file

1. Motivation and Description Virtual machines use grant table hypercalls to setup a share page for inter-VMs communications. These hypercalls are used by all PV protocols today. However, very

Re: [Xen-devel] [RFC PATCH v3 08/24] NUMA: x86: Move numa code and make it generic

Hi, On 18/07/17 16:29, Wei Liu wrote: On Tue, Jul 18, 2017 at 05:11:30PM +0530, vijay.kil...@gmail.com wrote: [...] diff --git a/xen/common/numa.c b/xen/common/numa.c new file mode 100644 index 000..0381f1b --- /dev/null +++ b/xen/common/numa.c @@ -0,0 +1,487 @@ +/* + * Common NUMA

Re: [Xen-devel] [RFC PATCH v3 07/24] ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA

Hi Vijay, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Right now CONFIG_NUMA is not enabled for ARM and existing code in asm-arm/numa.h is for !CONFIG_NUMA. Hence put this code under #ifndef CONFIG_NUMA. This help to make this changes work

Re: [Xen-devel] [RFC PATCH v3 23/24] NUMA: Move CONFIG_NUMA to common Kconfig

On 18/07/17 17:25, Julien Grall wrote: Hi, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K CONFIG_NUMA is defined in xen/drivers/acpi/Kconfig. Move to common/Kconfig and enabled by default. Also, NUMA feature uses PDX for physical address to

Re: [Xen-devel] [RFC PATCH v3 01/24] NUMA: Make number of NUMA nodes configurable

Hi, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Introduce NR_NODES config option to specify number of NUMA nodes supported. By default value is set at 64 for x86 and 8 for arm. Dropped NODES_SHIFT macro. Also move NR_NODE_MEMBLKS from

Re: [Xen-devel] [RFC PATCH v3 01/24] NUMA: Make number of NUMA nodes configurable

Hi, On 18/07/17 16:29, Wei Liu wrote: On Tue, Jul 18, 2017 at 05:11:23PM +0530, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Introduce NR_NODES config option to specify number of NUMA nodes supported. By default value is set at 64 for x86 and 8 for arm. Dropped

Re: [Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

On Mon, 17 Jul 2017, Roger Pau Monné wrote: > Hello, > > I didn't actually take notes, so this is from the top of my head. If > anyone took notes or remember something different, please feel free to > correct it. > > This is the output from the PVH toolstack interface session. The > participants

Re: [Xen-devel] [PATCH v3 1/2] x86/mm: Change default value for suppress #VE in set_mem_access()

On Tue, Jul 18, 2017 at 9:25 AM, Adrian Pop wrote: > From: Vlad Ioan Topan > > The default value for the "suppress #VE" bit set by set_mem_access() > currently depends on whether the call is made from the same domain (the > bit is set when called

Re: [Xen-devel] [PATCH v3 2/2] x86/altp2m: Add a hvmop for setting the suppress #VE bit

On Tue, Jul 18, 2017 at 9:25 AM, Adrian Pop wrote: > Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a > privileged domain to change the value of the #VE suppress bit for a > page. > > Add a libxc wrapper for invoking this hvmop. > > Signed-off-by: Adrian

[Xen-devel] [XTF PATCH v2 2/3] vlapic-timer: Test divide register configuration

Signed-off-by: Anthony PERARD --- arch/x86/include/arch/apic.h | 3 +++ tests/vlapic-timer/main.c| 40 2 files changed, 43 insertions(+) diff --git a/arch/x86/include/arch/apic.h b/arch/x86/include/arch/apic.h index

[Xen-devel] [XTF PATCH v2 0/3] Testing vlapic timer

Hi, Check the behavior of the vLAPIC timer emulation. This list of check works on baremetal if one managed to runned it (I did manual testing by coping this xtf tests into xen), but Xen emulation vlapic does not behave like baremetal, so this XTF tests would fail at first, until a fix for Xen

[Xen-devel] [XTF PATCH v2 1/3] vlapic-timer: Introduce vLAPIC Timer tests

Start by testing one-shot and periodic timer modes. The behavior of TMICT and TMCCT while switching between periodic and one-shot timer modes check in this test is mostly base on observation of baremetal. Intel SDM gives little details about it. Signed-off-by: Anthony PERARD

[Xen-devel] [XTF PATCH v2 3/3] vlapic-timer: Testing TSC-deadline timer mode

Signed-off-by: Anthony PERARD --- arch/x86/include/arch/apic.h | 1 + arch/x86/include/arch/cpuid.h | 1 + arch/x86/include/arch/lib.h | 9 ++ arch/x86/include/arch/msr-index.h | 1 + tests/vlapic-timer/main.c | 67

[Xen-devel] [qemu-mainline test] 111963: regressions - FAIL

flight 111963 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/111963/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 111765

[Xen-devel] [XenSummit 2017] Shared coprocessor framework followup

**Dear All, During the developers summit a Shared Coprocessor Framework (SCF) concept was presented. Noticeable interest from community was discovered during discussions. So this is a call for all interested parties to collect a feedback and setup a collaboration. There are several topics I

[Xen-devel] [PATCH v2 3/3] x86/vlapic: Apply change to TDCR right away to the timer

The description in the Intel SDM of how the divide configuration register is used: "The APIC timer frequency will be the processor's bus clock or core crystal clock frequency divided by the value specified in the divide configuration register." Observation of baremetal shown that when the TDCR is

[Xen-devel] [PATCH v2 1/3] x86/vlapic: Introduce vlapic_update_timer

There should not be any functionality change with this patch. This function is used when the APIC_TMICT register is updated. vlapic_update_timer is introduce as it will be use also when the registers APIC_LVTT and APIC_TDCR are updated. Signed-off-by: Anthony PERARD

[Xen-devel] [PATCH v2 0/3] Rework vlapic timer to behave more like real-hardware

Hi, When developing PVH for OVMF, I've used the lapic timer. It turns out that the way it is used by OVMF did not work with Xen [1]. I tried to find out how real-hw behave, and write a XTF tests [2]. And this patch series tries to fix the behavior of the vlapic timer. The OVMF driver for the

[Xen-devel] [PATCH v2 2/3] x86/vlapic: Keep timer running when switching between one-shot and periodic mode

If we take TSC-deadline mode timer out of the picture, the Intel SDM does not say that the timer is disable when the timer mode is change, either from one-shot to periodic or vice versa. After this patch, the timer is no longer disarmed on change of mode, so the counter (TMCCT) keeps counting

Re: [Xen-devel] XEN on R-Car H3 starter kit

Dear Ajeesh, I'm just courious, are you using an updated wiki [1]? [1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X -- *Andrii Anisov* ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] XEN on R-Car H3 starter kit

Dear Ajeesh, On 18.07.17 17:10, ajmalmalib4u wrote: I am using R-Car H3 hardware. ie. R-Car H3 Salvator-X. I am running Xen with Poky linux as Dom0 and DomU. Would i be able to run Xen with the same setup on R-Car H3 Starter Kit? You should have to apply appropriate changes to h3ulcb device

[Xen-devel] [libvirt test] 111966: tolerable all pass - PUSHED

flight 111966 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/111966/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 111915 test-armhf-armhf-libvirt-xsm 14

[Xen-devel] [PATCH] xen:Kconfig: Make SCIF built by default for ARM

From: Andrii Anisov Both Renesas R-Car Gen2(ARM32) and Gen3(ARM64) are utilizing SCIF IP, so make its serial driver built by default for ARM. Signed-off-by: Andrii Anisov --- xen/drivers/char/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [Xen-devel] [PATCH v3] xen/balloon: don't online new memory initially

On 07/18/2017 12:12 PM, Juergen Gross wrote: > On 18/07/17 18:08, Boris Ostrovsky wrote: >> On 07/10/2017 04:10 AM, Juergen Gross wrote: >>> When setting up the Xenstore watch for the memory target size the new >>> watch will fire at once. Don't try to reach the configured target size >>> by

Re: [Xen-devel] [RFC PATCH v3 11/24] ARM: fdt: Export and introduce new fdt functions

On 18/07/17 16:29, Wei Liu wrote: On Tue, Jul 18, 2017 at 05:11:33PM +0530, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Introduce new api device_tree_type_matches() to check for device type. Also export device_tree_get_u32() and device_tree_node_compatible()

Re: [Xen-devel] [RFC PATCH v3 23/24] NUMA: Move CONFIG_NUMA to common Kconfig

Hi, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K CONFIG_NUMA is defined in xen/drivers/acpi/Kconfig. Move to common/Kconfig and enabled by default. Also, NUMA feature uses PDX for physical address to memory node mapping. Hence make HAS_PDX

Re: [Xen-devel] [RFC PATCH v3 00/24] ARM: Add Xen NUMA support

Hi, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: This patch is tested on Thunderx platform. No changes are made to x86 implementation only code is sanitized and refactored. Hence only compilation tested for x86. This series is posted as RFC for the reason that it is not tested on x86.

Re: [Xen-devel] [RFC v2]Proposal to allow setting up shared memory areas between VMs from xl config file

On Tue, 18 Jul 2017, Zhongze Liu wrote: > Hi Julien, > > After our discussion during the summit, I have revised my plan, but > I'm still working on it and haven't sent it to the ML yet. > I'm planning to send a new version of my proposal together with the > parsing code later so that I could

Re: [Xen-devel] [PATCH v3] xen/balloon: don't online new memory initially

On 18/07/17 18:08, Boris Ostrovsky wrote: > On 07/10/2017 04:10 AM, Juergen Gross wrote: >> When setting up the Xenstore watch for the memory target size the new >> watch will fire at once. Don't try to reach the configured target size >> by onlining new memory in this case, as the current memory

Re: [Xen-devel] [PATCH v3] xen/balloon: don't online new memory initially

On 07/10/2017 04:10 AM, Juergen Gross wrote: > When setting up the Xenstore watch for the memory target size the new > watch will fire at once. Don't try to reach the configured target size > by onlining new memory in this case, as the current memory size will > be smaller in almost all cases due

Re: [Xen-devel] [PATCH 2/6] xl: Add commands for hiding and unhiding pcie passthrough devices

On Tue, Jul 18, 2017 at 02:38:14PM +0100, Wei Liu wrote: > On Fri, Jul 07, 2017 at 10:00:01AM -0400, Konrad Rzeszutek Wilk wrote: > > > > > > 1. PV PCI passthrough is done via pciback, which means the physical > > >device is assigned to the driver domain. All events to / from the > > >

Re: [Xen-devel] [RFC PATCH v3 11/24] ARM: fdt: Export and introduce new fdt functions

On Tue, Jul 18, 2017 at 05:11:33PM +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Introduce new api device_tree_type_matches() to check for > device type. Also export device_tree_get_u32() and > device_tree_node_compatible() > > These functions are

Re: [Xen-devel] [RFC PATCH v3 05/24] x86: NUMA: Add accessors for nodes[] and node_memblk_range[] structs

On Tue, Jul 18, 2017 at 05:11:27PM +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Add accessors for nodes[] and other static variables and > use those accessors. These variables are later accessed > outside the file when the code made generic in later >

Re: [Xen-devel] [RFC PATCH v3 03/24] x86: NUMA: Fix datatypes and attributes

On Tue, Jul 18, 2017 at 05:11:25PM +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Change u{8,32,64} to uint{8,32,64}_t, u64 to paddr_t > wherever applicable. > Fix attributes coding styles. > Also changed > - Some variables from int to unsigned int >

Re: [Xen-devel] [RFC PATCH v3 18/24] ACPI: Refactor acpi SRAT and SLIT table handling code

On Tue, Jul 18, 2017 at 05:11:40PM +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Move SRAT handling code which is common across > architectures is moved to new file xen/drivers/acpi/srat.c > from xen/arch/x86/srat.c file. New header file srat.h is >

Re: [Xen-devel] [RFC PATCH v3 01/24] NUMA: Make number of NUMA nodes configurable

On Tue, Jul 18, 2017 at 05:11:23PM +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Introduce NR_NODES config option to specify number > of NUMA nodes supported. By default value is set at > 64 for x86 and 8 for arm. Dropped NODES_SHIFT macro. > > Also

Re: [Xen-devel] [RFC PATCH v3 04/24] x86: NUMA: Rename and sanitize memnode shift code

On Tue, Jul 18, 2017 at 05:11:26PM +0530, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > memnode_shift variable is changed from int to unsigned int. > With this change, compute_memnode_shift() returns error value > instead of returning shift value. The

Re: [Xen-devel] [RFC PATCH v3 08/24] NUMA: x86: Move numa code and make it generic

On Tue, Jul 18, 2017 at 05:11:30PM +0530, vijay.kil...@gmail.com wrote: [...] > diff --git a/xen/common/numa.c b/xen/common/numa.c > new file mode 100644 > index 000..0381f1b > --- /dev/null > +++ b/xen/common/numa.c > @@ -0,0 +1,487 @@ > +/* > + * Common NUMA handling functions for x86 and

  1   2   3   >