Re: [Xen-devel] [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to inject MSR"

+Wei Thanks, -Xudong > -Original Message- > From: Zhang, PengtaoX > Sent: Friday, May 27, 2016 1:07 PM > To: Xen-devel > Cc: Hao, Xudong ; Zhang, Haozhong > > Subject: [BUG] xen's LLC, UCNA and MEM testing

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

flight 94808 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/94808/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 94743 Regressions

Re: [Xen-devel] [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to inject MSR"

On 05/27/16 13:07, Zhang, PengtaoX wrote: > Bug detailed description: > > On haswell-ex and boardwell-ex server, testing the xen's LLC, MEM, UCNA, > show error message:"Failed to inject MSR: Invalid argument". > > Environment : > > HW: haswell-ex/boardwell-ex

[Xen-devel] [PATCH] xen/arm: setup: initialize xenheap mappings after boot pages avaiable

To ARM64, setup_xenheap_mappings may call alloc_boot_pages to allocate first level page table, if there is a big chunk memory (ie, >512GB). So, need to make sure boot pages are ready before setup xenheap mappings. Signed-off-by: Peng Fan Cc: Julien Grall

[Xen-devel] [PATCH] xen/arm: setup: fix typo

Typo fix: fdt_get_mem_rsc -> fdt_get_mem_rsv Signed-off-by: Peng Fan Cc: Julien Grall Cc: Stefano Stabellini --- xen/arch/arm/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/arm/setup.c

[Xen-devel] [qemu-upstream-4.3-testing test] 94814: trouble: blocked/broken

flight 94814 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94814/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken

[Xen-devel] [BUG] xen's LLC, UCNA and MEM testing show error messge"Failed to inject MSR"

Bug detailed description: On haswell-ex and boardwell-ex server, testing the xen's LLC, MEM, UCNA, show error message:"Failed to inject MSR: Invalid argument". Environment : HW: haswell-ex/boardwell-ex Xen: Xen 4.7.0 RC3 Dom0: Linux 4.6.0 Reproduce steps:

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

flight 94802 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/94802/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 16 guest-start.2fail REGR. vs. 94789 Regressions which

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

Hi, > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Friday, May 27, 2016 12:56 AM > Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access > bit width support > > On 05/26/2016 12:26 PM, Jan Beulich wrote: > Boris Ostrovsky

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

Hi, > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Boris Ostrovsky > Sent: Thursday, May 26, 2016 3:17 AM > Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit > width support > > On 05/05/2016 12:58 AM, Lv Zheng wrote: > >

[Xen-devel] How about use different "max_grant_frames" for different domains?

Hi, Because the boosting CPU and memory resources on server, Xen users are allowed and actually do create lots of vdisk and vnic, e.g., 6 vnic, 20 vdisk and 24 vcpu (the number of vnic queue is proportional to the number of vcpu assigned to guest), and this requires the administrator to increase

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 2016年05月26日 16:42, Dong, Eddie wrote: > If enabling virtual Q35 solves the problem, it has the advantage: When more > and more virtual IOMMU feature comes (likely), we can reuse the KVM code for > Xen. > How big is the effort for virtual Q35? I think the most effort are to rebuild all ACPI

[Xen-devel] [qemu-upstream-4.3-testing test] 94806: trouble: blocked/broken

flight 94806 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94806/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken

[Xen-devel] [PATCH] arm/acpi: Fix the deadlock in function vgic_lock_rank()

Commit 9d77b3c01d1261c (Configure SPI interrupt type and route to Dom0 dynamically) causing dead loop inside the spinlock function. Note that spinlocks in XEN are not recursive. Re-acquiring a spinlock that has already held by calling CPU leads to deadlock. This happens whenever dom0 does writes

[Xen-devel] [PATCH] arm/acpi: Add Server Base System Architecture UART support

The ARM Server Base System Architecture describes a generic UART interface. It doesn't support clock control registers to set baudrate. So, extend the driver probe() to handle SBSA interface types and set the baudrate to 115200 for SBSA interfaces. Signed-off-by: Shanker Donthineni

[Xen-devel] [ovmf test] 94796: regressions - FAIL

flight 94796 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/94796/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748

[Xen-devel] [PATCH] arm/gic-v3: Fix driver probe fail on GICv4 hardware

The current driver probe fails on hardware which has GICv4 version, even though it is fully compatible to GICv3. This patch fixes the issue by registering the same probe function for GICv4 hardware. Signed-off-by: Shanker Donthineni --- xen/arch/arm/gic-v3.c | 13

[Xen-devel] [qemu-upstream-unstable test] 94800: tolerable FAIL - PUSHED

flight 94800 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/94800/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start.2 fail REGR. vs. 94765 Tests which did

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

On 05/26/2016 12:55 PM, Boris Ostrovsky wrote: > On 05/26/2016 12:26 PM, Jan Beulich wrote: > Boris Ostrovsky 05/25/16 9:17 PM >>> >>> On 05/05/2016 12:58 AM, Lv Zheng wrote: +static u8 +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8

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

flight 94795 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/94795/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 15 guest-start.2 fail REGR. vs. 94743 Regressions which

[Xen-devel] [qemu-upstream-4.3-testing test] 94801: trouble: blocked/broken

flight 94801 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94801/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken

[Xen-devel] [xen-unstable test] 94789: tolerable FAIL

flight 94789 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/94789/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail in 94780 pass in 94789

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

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94797: trouble: blocked/broken

flight 94797 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94797/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken

Re: [Xen-devel] balloon_mutex lockdep complaint at HVM domain destroy

On Wed, May 25, 2016 at 9:58 AM, David Vrabel wrote: > This occurs in dom0? Or the guest that's being destroyed? The lockdep warning comes from dom0 when the HVM guest is being destroyed. > It's a bug but... > >> ==

Re: [Xen-devel] [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu blocking list

Hi Feng, On Thu, 2016-05-26 at 21:39 +0800, Feng Wu wrote: > Feng Wu (4): >   VMX: Properly handle pi when all the assigned devices are removed >   VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed >   VMX: Assign the right value to 'NDST' field in a concern case >   VMX: fixup PI

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

On 05/26/2016 12:26 PM, Jan Beulich wrote: Boris Ostrovsky 05/25/16 9:17 PM >>> >> On 05/05/2016 12:58 AM, Lv Zheng wrote: >>> +static u8 >>> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 >>> max_bit_width) >>> +{ >>> +u64 address; >>> +

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

On Thu, May 26, 2016 at 05:10:52PM +0100, Anthony PERARD wrote: > On Thu, May 26, 2016 at 04:21:56PM +0100, Wei Liu wrote: > > From: Ian Jackson > > > > Each time round the main loop, we now fstat stderr. If it is too big, > > we dup2 /dev/null onto it. This is not a

Re: [Xen-devel] [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support

>>> Boris Ostrovsky 05/25/16 9:17 PM >>> >On 05/05/2016 12:58 AM, Lv Zheng wrote: >> +static u8 >> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 >> max_bit_width) >> +{ >> +u64 address; >> + >> +if (!reg->access_width) { >> +/* >>

Re: [Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue

On Thursday, May 26, 2016 11:57 PM, Jan Beulich wrote: > >>> "Xu, Quan" 05/26/16 12:38 PM >>> > >On May 25, 2016 4:30 PM, Jan Beulich wrote: > >> The patch getting too large is easy to deal with: Split it at a > >> reasonable boundary. >

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On May 26, 2016 04:40, "George Dunlap" wrote: > > On 26/05/16 04:55, Tamas K Lengyel wrote: > > Move sharing locks above altp2m to avoid locking order violation. Allow > > applying altp2m mem_access settings when the hostp2m entries are shared. > > Also, do not trigger

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

On Thu, 2016-05-26 at 13:03 +, Wu, Feng wrote: > > On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote: > > > > > > The patch fixing this issue has already been sent to upstream. > > > > > > " [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu > > > blocking list " > > > > > >

Re: [Xen-devel] Question about the usage of spinlock

On Thu, 2016-05-26 at 10:30 +0900, 조현권 wrote: > Hi > Hi, > I am studying xen 4.6.0 version now and wonder the usage of spinlock > which is located in free_heap_pages(xen/common/page_alloc. c) > As its memory setup is ahead of multicore initialization, spinlock > seems to be unnecessary during

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

On Thu, May 26, 2016 at 04:21:56PM +0100, Wei Liu wrote: > From: Ian Jackson > > Each time round the main loop, we now fstat stderr. If it is too big, > we dup2 /dev/null onto it. This is not a very pretty patch but it is > very simple, easy to see that it's correct,

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

On Thu, May 26, 2016 at 04:36:57PM +0100, George Dunlap wrote: > On Thu, May 26, 2016 at 4:21 PM, Wei Liu wrote: > > From: Ian Jackson > > > > Each time round the main loop, we now fstat stderr. If it is too big, > > we dup2 /dev/null onto it.

Re: [Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue

>>> "Xu, Quan" 05/26/16 12:38 PM >>> >On May 25, 2016 4:30 PM, Jan Beulich wrote: >> The patch getting too large is easy to deal with: Split it at a reasonable >> boundary. > >If I follow the below rule, I need to merge most of patches into this one. I

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

On Thu, May 26, 2016 at 4:21 PM, Wei Liu wrote: > From: Ian Jackson > > Each time round the main loop, we now fstat stderr. If it is too big, > we dup2 /dev/null onto it. This is not a very pretty patch but it is > very simple, easy to see that

Re: [Xen-devel] [PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

On Thu, May 26, 2016 at 04:47:59PM +0100, Wei Liu wrote: > On Thu, May 26, 2016 at 04:41:53PM +0100, Ian Jackson wrote: > > Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for > > QEMU"): > > > XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We > > > explicitly

Re: [Xen-devel] [PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU"): > XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We > explicitly set the limit in libxl for 4.7. ... > +unsigned long limit = 0; > +const char *s = getenv("XEN_QEMU_CONSOLE_LIMIT"); > + > +

Re: [Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

Wei Liu writes ("[PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups"): > The limit is 1Mby by default but can be adjusted by setting a new > environment variable. > > This fixes CVE-2014-3672. > > Signed-off-by: Ian Jackson > Tested-by:

Re: [Xen-devel] [PATCH v3 2/3] svm: iommu: Only call guest_iommu_init() after initialized HVM domain

>>> Suravee Suthikulanit 05/25/16 9:01 PM >>> >On 5/23/2016 6:54 AM, Jan Beulich wrote: > On 22.05.16 at 01:42, wrote: >>> From: Suravee Suthikulpanit >>> >>> The guest_iommu_init() is currently

Re: [Xen-devel] [PATCH v5 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

>>> "Xu, Quan" 05/26/16 3:42 AM >>> >On May 26, 2016 12:02 AM, Jan Beulich wrote: >> >>> On 25.05.16 at 17:34, wrote: >> > On May 23, 2016 10:19 PM, Jan Beulich wrote: >> >> >>> On 18.05.16 at 10:08,

Re: [Xen-devel] [PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

On Thu, May 26, 2016 at 04:41:53PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU"): > > XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We > > explicitly set the limit in libxl for 4.7. > ... > > +unsigned long limit = 0;

Re: [Xen-devel] [PATCH v3 3/3] AMD IOMMU: Check io_handler before registering mmio handler

>>> Suravee Suthikulanit 05/25/16 8:52 PM >>> >On 5/23/2016 3:23 AM, Paul Durrant wrote: >> > From: suravee.suthikulpa...@amd.com >> > Sent: 22 May 2016 00:43 >>> > guest_iommu_init tries to register mmio handler before HVM domain >>> > is initialized. This cause

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 26/05/16 15:05, Boris Ostrovsky wrote: > On 05/26/2016 06:24 AM, David Vrabel wrote: >>> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep, >>> pte_t pte) >>> * page tables for mapping the p2m list, too, and page tables MUST be >>> * mapped read-only. >>> */ >>>

[Xen-devel] [PATCH QEMU for-4.7] main loop: Big hammer to fix logfile disk DoS in Xen setups

From: Ian Jackson Each time round the main loop, we now fstat stderr. If it is too big, we dup2 /dev/null onto it. This is not a very pretty patch but it is very simple, easy to see that it's correct, and has a low risk of collateral damage. The limit is 1Mby by

[Xen-devel] [PATCH for-4.7] libxl: set XEN_QEMU_CONSOLE_LIMIT for QEMU

XSA-180 provides a patch to QEMU to bodge QEMU logging issue. We explicitly set the limit in libxl for 4.7. Introduce a function for setting the environment variable and call it in the right places. Signed-off-by: Wei Liu --- tools/libxl/libxl_dm.c | 33

[Xen-devel] [PATCH for-4.7] XSA-180 patches for 4.7

Two patches for XSA-180 for Xen 4.7 release. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about the usage of spinlock

Hello, On 26/05/2016 12:07, Xu, Quan wrote: On May 26, 2016 9:31 AM, 조현권 wrote: I am studying xen 4.6.0 version now and wonder the usage of spinlock which is located in free_heap_pages(xen/common/page_alloc. c) As its memory setup is ahead of multicore initialization,

[Xen-devel] [ANNOUNCEMENT] Xen 4.7 RC4

Hi all Xen 4.7 rc4 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.7.0-rc4 For you convenience there is also tarball at: http://bits.xensource.com/oss-xen/release/4.7.0-rc4/xen-4.7.0-rc4.tar.gz And the signature is at:

Re: [Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue

On May 26, 2016 6:38 PM, Xu, Quan wrote: > On May 25, 2016 4:30 PM, Jan Beulich wrote: > > The patch getting too large is easy to deal with: Split it at a > > reasonable boundary. > > Jan, > If I follow the below rule, I need to merge most of patches into

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 05/26/2016 06:24 AM, David Vrabel wrote: >> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep, >> pte_t pte) >> * page tables for mapping the p2m list, too, and page tables MUST be >> * mapped read-only. >> */ >> -pfn = pte_pfn(pte); >> +pfn = (pte &

[Xen-devel] [PATCH v2 4/4] VMX: fixup PI descritpor when cpu is offline

When cpu is offline, we need to move all the vcpus in its blocking list to another online cpu, this patch handles it. And we need to carefully handle the situation that calling to vmx_vcpu_block() and cpu offline occur concurrently. Signed-off-by: Feng Wu ---

[Xen-devel] [PATCH v2 3/4] VMX: Assign the right value to 'NDST' field in a concern case

Normally, in vmx_cpu_block() 'NDST' filed should have the same value with 'dest' or 'MASK_INSR(dest, PI_xAPIC_NDST_MASK)' depending on whether x2apic is enabled. However, in the following scenario, 'NDST' has different value: 'vcpu_block' hook gets assigned in vmx_pi_hooks_assign(), but all other

[Xen-devel] [PATCH v2 0/4] VMX: Properly handle pi descriptor and per-cpu blocking list

The current VT-d PI related code may operate incorrectly in the following scenarios: 1. When the last assigned device is dettached from the domain, all the PI related hooks are removed then, however, the vCPU can be blocked, switched to another pCPU, etc, all without the aware of PI. After the

[Xen-devel] [PATCH v2 1/4] VMX: Properly handle pi when all the assigned devices are removed

This patch handles some concern case when the last assigned device is removed from the domain. In this case we should carefully handle pi descriptor and the per-cpu blocking list, to make sure: - all the PI descriptor are in the right state when next time a devices is assigned to the domain again.

[Xen-devel] [PATCH v2 2/4] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

We should remove the vCPU from the per-cpu blocking list if it is going to be destroyed. Signed-off-by: Feng Wu --- xen/arch/x86/hvm/vmx/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 65f5288..b01128a

Re: [Xen-devel] [PATCH qemu-traditional] ioreq: Support 32-bit default_ioport_* accesses

Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH qemu-traditional] ioreq: Support 32-bit default_ioport_* accesses"): > On 05/25/2016 12:09 PM, Ian Jackson wrote: > > I think this question can only be resolved de jure by looking at what > > previous ACPI specifications (before this AccessSize

Re: [Xen-devel] [PATCH] x86/psr: make opt_psr persistent

On Thu, May 26, 2016 at 11:44:15AM +0100, Andrew Cooper wrote: > On 26/05/16 03:03, Chao Peng wrote: > > opt_psr is now not only used at booting time but also at runtime. > > More specifically, it is used to check CDP switch in psr_cpu_init() > > which can potentially be called in CPU hotplug

[Xen-devel] [qemu-upstream-4.3-testing test] 94790: trouble: blocked/broken

flight 94790 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94790/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

On Thu, May 26, 2016 at 01:03:53PM +, Wu, Feng wrote: > > > > -Original Message- > > From: Wei Liu [mailto:wei.l...@citrix.com] > > Sent: Thursday, May 26, 2016 6:27 PM > > To: Wu, Feng > > Cc: Hao, Xudong ; Xen-devel >

Re: [Xen-devel] [PATCH v5 3/6] build: convert verbose to Kconfig

On 05/24/2016 09:56 AM, Doug Goldstein wrote: Convert 'verbose', which was enabled by 'debug=y' to Kconfig as CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is enabled. Signed-off-by: Doug Goldstein Reviewed-by: Andrew Cooper

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: Thursday, May 26, 2016 6:27 PM > To: Wu, Feng > Cc: Hao, Xudong ; Xen-devel de...@lists.xenproject.org>; Wei Liu > Subject: Re: [BUG] Xen panic with

[Xen-devel] [ovmf test] 94784: regressions - FAIL

flight 94784 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/94784/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

On 26/05/16 09:29, Lan Tianyu wrote: > Hi All: > We try pushing virtual iommu support for Xen guest and there are some > features blocked by it. > > Motivation: > --- > 1) Add SVM(Shared Virtual Memory) support for Xen guest > To support iGFX pass-through for SVM enabled

Re: [Xen-devel] Question about the usage of spinlock

On May 26, 2016 9:31 AM, 조현권 wrote: > I am studying xen 4.6.0 version now and wonder the usage of spinlock which is > located in free_heap_pages(xen/common/page_alloc. c) > As its memory setup is ahead of multicore initialization, spinlock seems to > be unnecessary during

Re: [Xen-devel] [PATCH v2] xen: use vma_pages().

On 24/05/16 01:04, Muhammad Falak R Wani wrote: > Replace explicit computation of vma page count by a call to > vma_pages(). Applied to for-linus-4.8, thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/psr: make opt_psr persistent

On 26/05/16 03:03, Chao Peng wrote: > opt_psr is now not only used at booting time but also at runtime. > More specifically, it is used to check CDP switch in psr_cpu_init() > which can potentially be called in CPU hotplug case. > > Signed-off-by: Chao Peng

Re: [Xen-devel] [PATCH] x86/compat: correct SMEP/SMAP NOPs patching

On 25/05/16 16:00, Jan Beulich wrote: > Correct the number of single byte NOPs we want to be replaced in case > neither SMEP nor SMAP are available. > > Also simplify the expression adding these NOPs - at that location . > equals .Lcr4_orig, and removing that part of the expression fixes a > bogus

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On 26/05/16 04:55, Tamas K Lengyel wrote: > Move sharing locks above altp2m to avoid locking order violation. Allow > applying altp2m mem_access settings when the hostp2m entries are shared. > Also, do not trigger PoD for hostp2m when setting altp2m mem_access to be > in-line with non-altp2m

Re: [Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue

On May 25, 2016 4:30 PM, Jan Beulich wrote: > The patch getting too large is easy to deal with: Split it at a reasonable > boundary. Jan, If I follow the below rule, I need to merge most of patches into this one. I can't find a reasonable boundary. I recall your suggestion:

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

On 11/05/16 14:07, Arnd Bergmann wrote: > A bugfix patch for the xen balloon driver introduced a forward > declaration for a static function that is conditionally compiled, > causing a warning if only the declaration but not the definition > are there: > > drivers/xen/balloon.c:154:13: error:

Re: [Xen-devel] [PATCH v3 10/16] efi: create efi_enabled()

>>> @@ -42,11 +38,12 @@ UINT64 __read_mostly efi_boot_remain_var_store_size; >>> UINT64 __read_mostly efi_boot_max_var_size; >>> >>> struct efi __read_mostly efi = { >>> - .acpi = EFI_INVALID_TABLE_ADDR, >>> - .acpi20 = EFI_INVALID_TABLE_ADDR, >>> - .mps= EFI_INVALID_TABLE_ADDR, >>>

Re: [Xen-devel] [PATCH v2] xen/balloon: Fix declared-but-not-defined warning

On 10/05/16 10:27, Ross Lagerwall wrote: > Fix a declared-but-not-defined warning when building with > XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by > commit dfd74a1edfab > ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE"). Applied to for-linus-4.7b, thanks. I

Re: [Xen-devel] [PATCH v3 08/16] x86: add multiboot2 protocol support

>>> @@ -34,6 +57,42 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER >>> / >>> .long -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS) >>> multiboot1_header_end: >>> >>> +/*** MULTIBOOT2 HEADER / >>> +/* Some ideas are taken from

Re: [Xen-devel] [BUG] Xen panic with VT-d PI

On Thu, May 26, 2016 at 01:56:28AM +, Wu, Feng wrote: > The patch fixing this issue has already been sent to upstream. > > " [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list " > > v2 will be sent out soon. > I just went through that thread. There are some open

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

On 17/05/16 16:11, David Vrabel wrote: > On 11/05/16 11:16, David Vrabel wrote: >> >> Why don't we get the RW bits correct when making the pteval when we >> already have the pfn, instead trying to fix it up afterwards. > > Kevin, can you try this patch. > > David > > 8<- >

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

On Thu, 26 May 2016, Julien Grall wrote: > Hi Stefano, > > On 16/05/2016 12:11, Stefano Stabellini wrote: > > On Wed, 11 May 2016, Arnd Bergmann wrote: > > > A bugfix patch for the xen balloon driver introduced a forward > > > declaration for a static function that is conditionally compiled, > >

Re: [Xen-devel] [PATCH v3] AMD IOMMU: Introduce support for IVHD block type 11h

On 26/05/16 03:50, suravee.suthikulpa...@amd.com wrote: > From: Suravee Suthikulpanit > > Along with the IVHD block type 10h, newer AMD platforms also come with > types 11h, which is a superset of the older one. Having multiple IVHD > block types in the same

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

Hi Stefano, On 16/05/2016 12:11, Stefano Stabellini wrote: On Wed, 11 May 2016, Arnd Bergmann wrote: A bugfix patch for the xen balloon driver introduced a forward declaration for a static function that is conditionally compiled, causing a warning if only the declaration but not the definition

[Xen-devel] [qemu-upstream-4.3-testing test] 94787: trouble: blocked/broken

flight 94787 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94787/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken

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

flight 94780 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/94780/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 94756 build-amd64-rumpuserxen

Re: [Xen-devel] [for-4.7 2/2] xen/arm: Document the behavior of XENMAPSPACE_dev_mmio

Hi Stefano, On 26/05/2016 10:18, Stefano Stabellini wrote: On Wed, 25 May 2016, Julien Grall wrote: On 25/05/16 14:14, Jan Beulich wrote: Also - is Device_nGnRE a term uniform between ARM32 and ARM64? Actually it should be Device-nGnRE to match with the spec. This has been introduced on

Re: [Xen-devel] [for-4.7 2/2] xen/arm: Document the behavior of XENMAPSPACE_dev_mmio

On Wed, 25 May 2016, Julien Grall wrote: > Hi Jan, > > On 25/05/16 14:14, Jan Beulich wrote: > > > > > On 25.05.16 at 13:41, wrote: > > > --- a/xen/include/public/memory.h > > > +++ b/xen/include/public/memory.h > > > @@ -220,7 +220,10 @@

Re: [Xen-devel] [PATCH v3] xen-hvm: ignore background I/O sections

On Wed, 25 May 2016, Paolo Bonzini wrote: > > From: "Anthony PERARD" > > To: "Paul Durrant" > > Cc: qemu-de...@nongnu.org, xen-de...@lists.xenproject.org, "Stefano > > Stabellini" , "Paolo > > Bonzini"

Re: [Xen-devel] ARM Xen Bug #45: Is there a solution?

On 25/05/2016 16:10, Dirk Behme wrote: Hi Julien, Hello Dirk, On 24.05.2016 22:05, Julien Grall wrote: On 24/05/2016 14:39, Dirk Behme wrote: Hi Julien, Hello Dirk, On 23.05.2016 22:15, Julien Grall wrote: Hello Dirk, is there a solution for arm: domain 0 disables clocks which

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

If enabling virtual Q35 solves the problem, it has the advantage: When more and more virtual IOMMU feature comes (likely), we can reuse the KVM code for Xen. How big is the effort for virtual Q35? Thx Eddie > -Original Message- > From: Lan, Tianyu > Sent: Thursday, May 26, 2016 4:30 PM

[Xen-devel] Question about the usage of spinlock

Hi I am studying xen 4.6.0 version now and wonder the usage of spinlock which is located in free_heap_pages(xen/common/page_alloc. c) As its memory setup is ahead of multicore initialization, spinlock seems to be unnecessary during booting because it uses only single core spinlock looks

Re: [Xen-devel] [PATCH] xen: RTDS: fix another instance of the 'read NOW()' race

On 24/05/16 16:06, Dario Faggioli wrote: > which was overlooked in 779511f4bf5ae ("sched: avoid > races on time values read from NOW()"). > > Reported-by: Jan Beulich > Signed-off-by: Dario Faggioli Acked-by: George Dunlap

[Xen-devel] Discussion about virtual iommu support for Xen guest

Hi All: We try pushing virtual iommu support for Xen guest and there are some features blocked by it. Motivation: --- 1) Add SVM(Shared Virtual Memory) support for Xen guest To support iGFX pass-through for SVM enabled devices, it requires virtual iommu support to emulate

Re: [Xen-devel] [PATCH v5 3/6] build: convert verbose to Kconfig

Hi Doug, On 24/05/2016 14:56, Doug Goldstein wrote: Convert 'verbose', which was enabled by 'debug=y' to Kconfig as CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is enabled. Signed-off-by: Doug Goldstein Reviewed-by: Andrew Cooper

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

> -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: 25 May 2016 21:58 > To: Paul Durrant; zhigang.x.w...@oracle.com > Cc: Wei Liu; Olaf Hering; Stefano Stabellini; Andrew Cooper; xen- > de...@lists.xen.org; Anthony Perard > Subject: Re: [Xen-devel]

Re: [Xen-devel] [PATCH v3 3/3] AMD IOMMU: Check io_handler before registering mmio handler

> -Original Message- > From: Suravee Suthikulanit [mailto:suravee.suthikulpa...@amd.com] > Sent: 25 May 2016 19:52 > To: Paul Durrant; xen-devel@lists.xen.org; jbeul...@suse.com; George > Dunlap > Cc: Keir (Xen.org) > Subject: Re: [PATCH v3 3/3] AMD IOMMU: Check io_handler before >

Re: [Xen-devel] [PATCH] x86/mce: handle DOMID_XEN properly in XEN_MC_msrinject

On 05/26/16 09:15, Egger, Christoph wrote: > On 26/05/16 03:07, Haozhong Zhang wrote: > > Commit 26646f3 "x86/mce: translate passed-in GPA to host machine > > address" forgot to consider dom_xen, which fails tools/xen-mceinj when > > it's going to inject into domain DOMID_XEN (e.g. when -d option

[Xen-devel] [PATCH v2 1/4] xen/arm: Change the variable type of cpu_logical_map to register_t

The cpu_logical_map is used to store CPU hardware ID from MPIDR_EL1 or from CPU node of DT. Currently, the cpu_logical_map is using the u32 as its variable type. It can work properly while Xen is running on ARM32, because the hardware ID is 32-bits. While Xen is running on ARM64, the hardware ID

[Xen-devel] [PATCH v2 2/4] xen/arm: Make AFFINITY_MASK generate correct mask for level3

The original affinity shift bits algorithm in AFFINITY_MASK is buggy, it could not generate correct affinity shift bits of level3. The macro MPIDR_LEVEL_SHIFT can calculate level3 affinity shift bits correctly. We use this macro in AFFINITY_MASK to generate correct mask for level3. Signed-off-by:

[Xen-devel] [PATCH v2 0/4] xen/arm: arm64: Widen register access to mpidr to 64-bits

In ARM64 the MPIDR register is mapped to MPIDR_EL1, and the register bits are expanded to 64-bits. But Xen 64-bit ARM code treats this it as 32-bit register. We have to provide correct accessing to this register to avoid unexpected issues that is caused by incorrect MPIDR value. Wei Chen (4):

[Xen-devel] [PATCH v2 3/4] xen:arm: arm64: Add correct MPIDR_HWID_MASK value for ARM64

Currently, MPIDR_HWID_MASK is using the bit definition of AArch32 MPIDR. From ARMv8 ARM we can see there are 4 levels of affinity on AArch64 whilst AArch32 has only 3. So, this value is not correct when Xen is running on AArch64. Now, we use the value 0xff00ff for this macro on AArch64. But

[Xen-devel] [PATCH v2 4/4] xen/arm: arm64: Remove MPIDR multiprocessing extensions check

In AArch32, MPIDR bit31 is defined as multiprocessing extensions bit. But in AArch64, this bit is always RES1. So the value check for this bit is no longer necessary in AArch64. Signed-off-by: Wei Chen --- v2: Make clear the status of MPIDR.SMP bit in AArch32 and AArch64.

Re: [Xen-devel] [PATCH] x86/mce: handle DOMID_XEN properly in XEN_MC_msrinject

On 26/05/16 03:07, Haozhong Zhang wrote: > Commit 26646f3 "x86/mce: translate passed-in GPA to host machine > address" forgot to consider dom_xen, which fails tools/xen-mceinj when > it's going to inject into domain DOMID_XEN (e.g. when -d option is not > used) via XEN_MC_msrinject. Use dom_xen

  1   2   >