[Xen-devel] Xen development link

Hi, I came across Xen development link ( https://xenorg.uservoice.com/forums/172169-xen-development ) which was lastly updated in Jul 2017 ( around ). This looks great to me, but just wanted to check if we are still following and updating the ideas ? Or is there any other link / forum, where we

[Xen-devel] [xen-4.9-testing test] 121728: FAIL

flight 121728 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/121728/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-3 broken in 121358 Tests

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

flight 121734 rumprun real [real] http://logs.test-lab.xenproject.org/osstest/logs/121734/ 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-4.7-testing test] 121725: trouble: broken/fail/pass

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

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

On Sat, 31 Mar 2018, Julien Grall wrote: > On Sat, 31 Mar 2018, 00:27 Stefano Stabellini, wrote: > On Fri, 30 Mar 2018, Amit Tomer wrote: > > Hello, > > > > > I tested this on my board and it works like expected. I would very > much > > >

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

On Tue, 3 Apr 2018, Julien Grall wrote: > Hi, > > On 16/03/18 17:15, Julien Grall wrote: > > > > > > On 16/03/2018 16:56, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 16/03/2018 16:33, Stefano Stabellini wrote: > > > > On Fri, 16 Mar 2018, Julien Grall wrote: > > > > > Hi Stefano, > >

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

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

[Xen-devel] [PATCH 1/8] x86/SVM: Modify VMCB fields to add AVIC support

From: Suravee Suthikulpanit Introduce AVIC-related VMCB fields. Signed-off-by: Suravee Suthikulpanit Signed-off-by: Janakarajan Natarajan --- xen/include/asm-x86/hvm/svm/vmcb.h | 23

[Xen-devel] [PATCH 6/8] x86/HVM: Hook up miscellaneous AVIC functions

From: Suravee Suthikulpanit This patch modifies the hvm_function_table.virtual_intr_delivery_enabled() to become a bool variable as both VMX and SVM simply return static value. Also, this patch hooks up virtual_intr_delivery_enabled and deliver_posted_intr

[Xen-devel] [PATCH 3/8] x86/SVM: Add AVIC vmexit handlers

From: Suravee Suthikulpanit AVIC introduces two new #vmexit handlers: VMEXIT_INCOMP_IPI: This occurs when an IPI could not be delivered to all targeted guest virtual processors because at least one guest virtual processor was not allocated to a physical core at

[Xen-devel] [PATCH 8/8] x86/SVM: Add AMD AVIC key handler

From: Suravee Suthikulpanit Adding new key-handler "j" for dumping AVIC-related information. Here is an example of per-domain statistics being dumped. *** SVM AVIC Statistics ** >>> Domain 1 <<< VCPU 0 * incomp_ipi =

[Xen-devel] [PATCH 0/8] Introduce AMD SVM AVIC

OVERVIEW This patchset is the first of a two-part patch series to introduce the AMD Advanced Virtual Interrupt Controller (AVIC) support. The AVIC hardware virtualizes local APIC registers of each vCPU via the virtual APIC (vAPIC) backing page. This allows the guest to access certain

[Xen-devel] [PATCH 4/8] x86/SVM: Add vcpu scheduling support for AVIC

From: Suravee Suthikulpanit Add hooks to manage AVIC data structure during vcpu scheduling. Signed-off-by: Suravee Suthikulpanit Signed-off-by: Janakarajan Natarajan --- xen/arch/x86/hvm/svm/avic.c |

[Xen-devel] [PATCH 5/8] x86/SVM: Add interrupt management code via AVIC

From: Suravee Suthikulpanit Enabling AVIC implicitly disables the V_IRQ, V_INTR_PRIO, V_IGN_TPR, and V_INTR_VECTOR fields in the VMCB Control Word. Therefore, this patch introduces new interrupt injection code via AVIC backing page. Signed-off-by: Suravee

[Xen-devel] [PATCH 7/8] x86/SVM: Introduce svm command line option

From: Suravee Suthikulpanit This patch introduces a new Xen command line option to enable/disable SVM sub-options. Currently, it support sub-option "avic", which can be used to enable/disable SVM AVIC feature. Signed-off-by: Suavee Suthikulpant

[Xen-devel] [PATCH 2/8] x86/HVM/SVM: Add AVIC initialization code

From: Suravee Suthikulpanit Introduce AVIC base initialization code. This includes: * Setting up per-VM data structures. * Setting up per-vCPU data structure. * Initializing AVIC-related VMCB bit fields. This patch also introduces a new Xen parameter

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

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

[Xen-devel] Reminder: Xen ARM Community Call Wednesday 4th April 4PM UTC

Just a quick reminder that tomorrow, the 4th of April, we are going to have a Xen on ARM Community call at 9AM California time, 5PM UK time. These are the details of the call: Join the call: https://www.uberconference.com/stefano-stabellini Optional dial in number: 669-999-0613 No PIN needed

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

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

On Tue, Apr 03, 2018 at 05:36:07PM +, osstest service owner wrote: > flight 121721 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/121721/ > > test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install > fail REGR. vs. 121272 >

Re: [Xen-devel] [PATCH v4 1/8] x86: NOP out XPTI entry/exit code when it's not in use

On 19/03/18 14:37, Jan Beulich wrote: > Introduce a synthetic feature flag to use alternative instruction > patching to NOP out all code on entry/exit paths. Having NOPs here is > generally better than using conditional branches. > > Also change the limit on the number of bytes we can patch in

[Xen-devel] [xen-unstable test] 121721: regressions - FAIL

flight 121721 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/121721/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 121272

Re: [Xen-devel] [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote: > On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote: > > > > On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > > > > > > Initialize UEFI secure boot state during dom0 boot. Otherwise the > > > kernel may not even know

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvhv2-amd

On 03/04/18 12:29, Juergen Gross wrote: > On 03/04/18 12:19, osstest service owner wrote: >> branch xen-unstable >> xenbranch xen-unstable >> job test-amd64-amd64-xl-pvhv2-amd >> testid guest-start >> >> Tree: linux >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> Tree:

[Xen-devel] [RFC PATCH 1/1] xen: credit2: rb-tree for runqueues

The patch optimized the sorted credit2 runq from simple linked list to rb-tree implementation. This way we will gain performance and scalability when the number of vCPUs are huge. Signed-off-by: Praveen Kumar --- xen/common/sched_credit2.c | 94

[Xen-devel] [RFC PATCH 0/1] xen: credit2: rb-tree for runqueues

Hi All, This is the continued work with respect to rb-tree usage in Credit2, as mentioned in previous conversations https://lists.xen.org/archives/html/xen-devel/2017-06/msg01968.html The patch optimized the Credit2 runqueue from sorted queue to rb-tree. This will help in performance and

Re: [Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors [and 1 more messages]

Venu Busireddy writes ("Re: [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors [and 1 more messages]"): > On 2018-04-03 16:06:17 +0100, Ian Jackson wrote: > > Ian Jackson writes ("Re: [PATCH v3 1/2] libxl: Implement the handler to > > handle unrecoverable AER

Re: [Xen-devel] [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote: > On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > > Initialize UEFI secure boot state during dom0 boot. Otherwise the > > kernel > > may not even know that it runs on secure boot enabled platform. > > > > Signed-off-by:

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

Hi, On 28/03/18 04:51, Manish Jaggi wrote: On 03/27/2018 05:08 PM, Marc Zyngier wrote: On 27/03/18 12:27, Manish Jaggi wrote: On 03/27/2018 04:55 PM, Marc Zyngier wrote: On 27/03/18 12:15, Manish Jaggi wrote: On 03/27/2018 04:41 PM, Marc Zyngier wrote: On 27/03/18 12:07, Manish Jaggi

[Xen-devel] [PATCH v4] x86/setup: disallow any src/dst overlaps when relocating Xen image

Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image placement) disallowed src/dst images overlaps when relocating Xen image. Though it deliberately allowed destination region between __image_base__ and (__image_base__ + XEN_IMG_OFFSET) overlaps with the end of source image. And

Re: [Xen-devel] [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > Initialize UEFI secure boot state during dom0 boot. Otherwise the > kernel > may not even know that it runs on secure boot enabled platform. > > Signed-off-by: Daniel Kiper > --- >  arch/x86/xen/efi.c   

[Xen-devel] [for-4.11][PATCH v7 15/16] xen/x86: Switch mfn_to_page in x86_64/mm.c to use typesafe MFN

Other than MFN 0 -> INVALID_MFN, no functional change intended. Signed-off-by: Julien Grall Acked-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Changes in v6: - s/_mfn(0)/MFN 0/

Re: [Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

Hi, On 28/03/18 04:48, Manish Jaggi wrote: On 03/28/2018 06:18 AM, Julien Grall wrote: Hi, Sorry for the formatting. On Wed, 28 Mar 2018, 04:18 Stefano Stabellini, > wrote: On Tue, 27 Mar 2018, Marc Zyngier wrote: > On

[Xen-devel] [for-4.11][PATCH v7 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

At the same time replace MFN 0 by INVALID_MFN or drop the initializer when it is not necessary. This will make clearer that the MFN initialized is not valid. Other than MFN 0 -> INVALID_MFN, no functional change intended. Signed-off-by: Julien Grall Reviewed-by: Jan

[Xen-devel] [for-4.11][PATCH v7 02/16] xen/arm: setup: use maddr_to_mfn rather than _mfn(paddr_to_pfn(...))

Signed-off-by: Julien Grall Reviewed-by: George Dunlap --- Cc: Stefano Stabellini Changes in v6: - Remove the justification from the commit message - Add George's reviewed-by Changes in v4:

[Xen-devel] [for-4.11][PATCH v7 04/16] xen/arm: mm: Remove unused M2P code

Arm does not have an M2P and very unlikely to get one in the future, therefore don't keep defines that are not necessary in the common code. At the same time move the remaining M2P define just above set_gpfn_from_mfn to keep all the dummy helpers for M2P together. Signed-off-by: Julien Grall

[Xen-devel] [for-4.11][PATCH v7 11/16] xen/mm: Switch some of page_alloc.c to typesafe MFN

No functional change intended. Signed-off-by: Julien Grall Reviewed-by: Wei Liu Reviewed-by: George Dunlap --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

[Xen-devel] [for-4.11][PATCH v7 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

Most of the users of page_to_mfn and mfn_to_page are either overriding the macros to make them work with mfn_t or use mfn_x/_mfn because the rest of the function use mfn_t. So make page_to_mfn and mfn_to_page return mfn_t by default. The __* version are now dropped as this patch will convert all

[Xen-devel] [for-4.11][PATCH v7 10/16] xen/mm: Switch map_pages_to_xen to use MFN typesafe

The current prototype is slightly confusing because it takes a virtual address and a physical frame (not address!). Switching to MFN will improve safety and reduce the chance to mistakenly invert the 2 parameters. Also, take the opportunity to switch (a - b) >> PAGE_SHIFT to PFN_DOWN(a - b) in

[Xen-devel] [for-4.11][PATCH v7 07/16] xen/x86: mm: Switch x86/mm.c to use typesafe for virt_to_mfn

No functional change intended. While we are here, use PFN_DOWN() rather than open coding it. Signed-off Julien Grall Acked-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Changes in v6:

[Xen-devel] [for-4.11][PATCH v7 03/16] xen/arm: mm: Use gaddr_to_gfn rather than _gfn(paddr_to_pfn(...))

Signed-off-by: Julien Grall Reviewed-by: George Dunlap --- Cc: Stefano Stabellini Changes in v7: - Add George's reviewed-by Changes in v6: - Remove the justification from the commit message

[Xen-devel] [for-4.11][PATCH v7 13/16] xen/grant: Switch {create, replace}_grant_p2m_mapping to typesafe MFN

The current prototype is slightly confusing because it takes a guest physical address and a machine physical frame (not address!). Switching to MFN will improve safety and reduce the chance to mistakenly invert the 2 parameters. Signed-off-by: Julien grall Reviewed-by: Wei

[Xen-devel] [for-4.11][PATCH v7 06/16] xen/x86: Remove unused override of page_to_mfn/mfn_to_page

A few files override page_to_mfn/mfn_to_page but actually never use those macros. So drop them. Signed-off-by: Julien Grall Acked-by: George Dunlap Acked-by: Jan Beulich --- Cc: George Dunlap Cc:

[Xen-devel] [for-4.11][PATCH v7 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

A new helper __copy_mfn_to_guest is introduced to easily to copy a MFN to the guest memory. Not functional change intended Signed-off-by: Julien Grall Reviewed-by: Jan Beulich --- Cc: Andrew Cooper Cc: George Dunlap

[Xen-devel] [for-4.11][PATCH v7 09/16] xen/pdx: Introduce helper to convert MFN <-> PDX

This will avoid use of pfn_to_pdx(mfn_x(mfn)) over the code base. Signed-off-by: Julien Grall Reviewed-by: Wei Liu Acked-by: Andrew Cooper --- Cc: Andrew Cooper Cc: George Dunlap

[Xen-devel] [for-4.11][PATCH v7 01/16] x86/mm: skip incrementing mfn if it is not a valid mfn

From: Wei Liu In a follow-up patch, some callers will be switched to pass INVALID_MFN instead of zero for non-present mappings. So skip incrementing mfn if it is not a valid one. Signed-off-by: Wei Liu Signed-off-by: Julien Grall

[Xen-devel] [for-4.11][PATCH v7 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

The function populate_pt_range is used to populate in advance the page-table but it will not do the actual mapping. So passing the MFN in parameter is pointless. Note that the only caller pass 0... At the same time replace 0 by INVALID_MFNs. While this does not matter as the entry will marked as

[Xen-devel] [for-4.11][PATCH v7 05/16] xen/arm: mm: Remove unused relinquish_shared_pages

relinquish_shared_pages is never called on Arm. Signed-off-by: Julien Grall Reviewed-by: George Dunlap --- Cc: Stefano Stabellini Changes in v6: - Add George's reviewed-by Changes in v4: - Patch

Re: [Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors [and 1 more messages]

On 2018-04-03 16:06:17 +0100, Ian Jackson wrote: > Venu Busireddy writes ("[RESEND 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 > >

Re: [Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors [and 1 more messages]

On Tue, 3 Apr 2018 16:06:17 +0100 Ian Jackson wrote: > Venu Busireddy writes ("[RESEND 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

Re: [Xen-devel] [PATCH] Add pvcalls info to xl man page and add missing LIBXL_HAVE_PVCALLS

On Tue, Apr 03, 2018 at 11:29:07AM +0100, Roger Pau Monné wrote: > On Fri, Mar 30, 2018 at 10:31:53AM -0700, Stefano Stabellini wrote: > > Add a short entry to the xl.cfg man page about pvcalls. > > Also add LIBXL_HAVE_PVCALLS to mark the presence of pvcalls support in > > libxl. > > > >

Re: [Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors [and 1 more messages]

Venu Busireddy writes ("[RESEND 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

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

On Mon, Apr 02, 2018 at 11:05:17PM -0700, Maran Wilson wrote: > > Boris Ostrovsky (3): > libxl/x86: Build e820 map earlier for HVM/PVH guests > libxl: Store e820 map in xc_dom_image > libxc: Pass e820 map to HVM/PVH guests via hvm_start_info > > Maran Wilson (1): > x86/PVHv2: Add memory

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

Hi, On 16/03/18 17:15, Julien Grall wrote: On 16/03/2018 16:56, Julien Grall wrote: Hi Stefano, On 16/03/2018 16:33, Stefano Stabellini wrote: On Fri, 16 Mar 2018, Julien Grall wrote: Hi Stefano, On 15/03/18 23:52, Stefano Stabellini wrote: On Wed, 14 Mar 2018, Stefano Stabellini wrote:

[Xen-devel] [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel may not even know that it runs on secure boot enabled platform. Signed-off-by: Daniel Kiper --- arch/x86/xen/efi.c| 57 +

Re: [Xen-devel] [PATCH v19 06/11] x86/hvm/ioreq: add a new mappable resource type...

> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 03 April 2018 15:08 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: Jan Beulich ; George Dunlap > ; Wei Liu ;

Re: [Xen-devel] [PATCH v19 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 03 April 2018 15:05 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: George Dunlap ; Andrew Cooper > ; Ian Jackson

Re: [Xen-devel] [PATCH v19 06/11] x86/hvm/ioreq: add a new mappable resource type...

Hi Paul, On 29/03/18 16:36, Paul Durrant wrote: diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index a0e922f360..8cddf484d8 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -374,6 +374,14 @@ static inline void put_page_and_type(struct page_info *page)

Re: [Xen-devel] [PATCH v19 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

Hi Paul, On 29/03/18 16:36, Paul Durrant wrote: Certain memory resources associated with a guest are not necessarily present in the guest P2M. This patch adds the boilerplate for new memory op to allow such a resource to be priv-mapped directly, by either a PV or HVM tools domain. NOTE:

Re: [Xen-devel] [PATCH v5 4/4] libxc: Pass e820 map to HVM/PVH guests via hvm_start_info

On Mon, Apr 02, 2018 at 11:05:21PM -0700, Maran Wilson wrote: > From: Boris Ostrovsky > > Signed-off-by: Boris Ostrovsky > Signed-off-by: Maran Wilson Reviewed-by: Roger Pau Monné Thanks,

Re: [Xen-devel] [PATCH] ARM: new VGIC: evtchn: fix potential race in vcpu_mark_events_pending()

On 29/03/18 18:35, Stefano Stabellini wrote: On Thu, 29 Mar 2018, Andre Przywara wrote: Stefano pointed out the following situation: -- 1) vcpuA/cpuA is running, it has already handled the event, cleared evtchn_upcall_pending and EOIed the event_irq but hasn't trapped into

[Xen-devel] [PATCH v2 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support

Signed-off-by: Amit Singh Tomar --- Changes since v1: * Removed header file dependency. --- docs/misc/arm/early-printk.txt | 1 + xen/arch/arm/Rules.mk | 1 + xen/arch/arm/arm64/debug-mvebu.inc | 50

[Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

This patch adds driver for UART controller found on Armada 3700 SoC. There is no reference manuals available for 3700 SoC in public and it is derived by looking at Linux driver[1]. [1]https://github.com/torvalds/linux/blob/master/drivers/tty/serial/mvebu-uart.c Signed-off-by: Amit Singh Tomar

[Xen-devel] [PATCH 0/2] Add support for Marvell Armada 3700 SoC

This patch-set enables XEN booting[1] on ESPRESSObin board based on Marvell Armada 3700 SoC. I would like to Thanks Andre for helping on this. [1]https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/ESPRESSObin Amit Singh Tomar (2): xen/arm: Add MVEBU UART driver for Marvell

Re: [Xen-devel] [PATCH v5 3/4] libxl: Store e820 map in xc_dom_image

On Mon, Apr 02, 2018 at 11:05:20PM -0700, Maran Wilson wrote: > 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 ^ claiming > only used for

Re: [Xen-devel] [PATCH v5 2/4] libxl/x86: Build e820 map earlier for HVM/PVH guests

On Mon, Apr 02, 2018 at 11:05:19PM -0700, Maran Wilson wrote: > From: Boris Ostrovsky > > Since hvm_start_info has now been expanded to include memory map (i.e. > e820) we need to know size of this map by the time we create > dom->start_info_seg in

Re: [Xen-devel] [PATCH] MAINTAINERS: Add drm/xen-front maintainer entry

On 04/03/2018 03:32 PM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add myself as drivers/gpu/drm/xen maintainer. Signed-off-by: Oleksandr Andrushchenko --- MAINTAINERS | 9 + 1 file changed, 9

Re: [Xen-devel] [PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly

Hi Stefano, On 28/03/18 01:01, Stefano Stabellini wrote: On Wed, 21 Mar 2018, Andre Przywara wrote: The event channel IRQ has level triggered semantics, however the current VGIC treats everything as edge triggered. To correctly process those IRQs, we have to lower the (virtual) IRQ line at

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

flight 121720 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/121720/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 119227 Tests

Re: [Xen-devel] [PATCH v3 33/39] ARM: new VGIC: Add preliminary stub implementation

Hi Stefano, On 27/03/18 23:48, Stefano Stabellini wrote: On Wed, 21 Mar 2018, 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 make

[Xen-devel] [PATCH] MAINTAINERS: Add drm/xen-front maintainer entry

From: Oleksandr Andrushchenko Add myself as drivers/gpu/drm/xen maintainer. Signed-off-by: Oleksandr Andrushchenko --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index

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

On 04/03/2018 02:23 PM, Oleksandr Andrushchenko wrote: Resending with even more checkpatch code-style fixes. Applied, thank you! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

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

flight 121714 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/121714/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 10 debian-install fail REGR. vs. 121336 test-armhf-armhf-xl

[Xen-devel] [PATCH v6 RESEND 1/1] 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 v6 RESEND 0/1] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Resending with even more checkpatch code-style fixes. Hello! Boris/Daniel, I put your R-b tags, so please do let me know if this is not acceptable, so I remove the tags. This patch series adds support for Xen [1] para-virtualized

Re: [Xen-devel] [PATCH v1] xen-blkfront: dynamic configuration of per-vbd resources

On Mon, Apr 02, 2018 at 01:42:32PM -0400, Konrad Rzeszutek Wilk wrote: > From: Bob Liu > > The current VBD layer reserves buffer space for each attached device based on > three statically configured settings which are read at boot time. > * max_indirect_segs: Maximum amount

[Xen-devel] [PATCH v1] xl: show full value of cpu_khz in xl info output

The exact value of cpu_khz can only be obtained via 'xl dmesg', and therefore can be lost after some time. 'xl info' truncates the value to full MHz. Adjust the output to show the full khz value. This helps the host admin to track how a host has calibrated itself. The value of cpu_khz is used

Re: [Xen-devel] [PATCH] Add pvcalls info to xl man page and add missing LIBXL_HAVE_PVCALLS

On Fri, Mar 30, 2018 at 10:31:53AM -0700, Stefano Stabellini wrote: > Add a short entry to the xl.cfg man page about pvcalls. > Also add LIBXL_HAVE_PVCALLS to mark the presence of pvcalls support in > libxl. > > Signed-off-by: Stefano Stabellini > --- >

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvhv2-amd

On 03/04/18 12:19, osstest service owner wrote: > branch xen-unstable > xenbranch xen-unstable > job test-amd64-amd64-xl-pvhv2-amd > testid guest-start > > Tree: linux > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > Tree: linuxfirmware

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvhv2-amd

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-pvhv2-amd testid guest-start 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

Re: [Xen-devel] [PATCH 1/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > +static int to_refs_grant_foreign_access(struct xen_gem_object *xen_obj) > +{ > + grant_ref_t priv_gref_head; > + int ret, j, cur_ref, num_pages; >

[Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Hello! Boris/Daniel, I put your R-b tags, so please do let me know if this is not acceptable, so I remove the tags. This patch series adds support for Xen [1] para-virtualized frontend display driver. It implements the protocol

Re: [Xen-devel] [PATCH v4 7/7] xen/x86: use PCID feature

On 29/03/18 17:37, Jan Beulich wrote: On 29.03.18 at 17:15, wrote: >> On 29/03/18 16:19, Jan Beulich wrote: >> On 27.03.18 at 11:07, wrote: @@ -102,7 +103,21 @@ void write_cr3_cr4(unsigned long cr3, unsigned long cr4) t =

[Xen-devel] [linux-4.9 test] 121711: trouble: broken/fail/pass

flight 121711 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/121711/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 broken Tests which

[Xen-devel] [PATCH v5 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 v5 3/4] libxl: Store 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 --- Cc: Ian Jackson

[Xen-devel] [PATCH v5 2/4] libxl/x86: Build e820 map earlier for HVM/PVH guests

From: Boris Ostrovsky Since hvm_start_info has now been expanded to include 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 libxl__arch_domain_construct_memmap()

[Xen-devel] [PATCH v5 4/4] libxc: Pass e820 map to HVM/PVH guests via hvm_start_info

From: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Maran Wilson --- Cc: Ian Jackson Cc: Wei Liu Cc: Roger Pau Monné Cc: Boris

[Xen-devel] [PATCH v5 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: