[Xen-devel] [PATCH] xen/arm: p2m: Remove p2m_operation

This is a left over of before the P2M code was reworked. So drop it. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 4 1 file changed, 4 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 7b2aac4c90..c484469e6c 100644 ---

[Xen-devel] [PATCH 00/11] xen/arm: Clean-up traps.c

Hi all, xen/arch/arm/traps.c is beginning to get very big. This series is moving out the co-processor and sysreg emulate in separate files. This will avoid to grow traps.c when adding more registers emulations (coming soon). A branch with this series has been pushed:

[Xen-devel] [PATCH 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

From: Manish Jaggi estimate_acpi_efi_size needs to be updated to provide correct size of hardware domains MADT, which now adds ITS information as well. Introducing gic_get_hwdom_madt_size. Signed-off-by: Manish Jaggi --- xen/arch/arm/domain_build.c

[Xen-devel] [PATCH 3/5] ARM: ITS: Deny hardware domain access to its

From: Manish Jaggi This patch extends the gicv3_iomem_deny_access functionality by adding support for its region as well. Added function gicv3_its_deny_access. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 19 +++

[Xen-devel] [PATCH 2/2] ARM: ITS: Populate host_its_list from ACPI MADT Table

From: Manish Jaggi Added gicv3_its_acpi_init to update host_its_list from MADT table. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 14 ++ xen/arch/arm/gic-v3.c| 8 xen/include/asm-arm/gic_v3_its.h |

[Xen-devel] [PATCH 5/5] ARM: ITS: Pass ITS in Hardware Domain MADT

From: Manish Jaggi Adds gicv3_its_make_hwdom_madt to update hwdom MADT ITS information. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 24 xen/arch/arm/gic-v3.c| 1 +

Re: [Xen-devel] [PATCH for-2.10 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote: > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be > set, but this was done only when ACPI tables are built which is not > needed for a Xen guest. The need for the property starts with commit > "pc: pcihp:

[Xen-devel] [PATCH 1/5] ARM: ITS: Introduce common function add_to_host_its_list

From: Manish Jaggi add_to_host_its_list will update the host_its_list. This common function to be invoked from gicv3_its_dt_init and gic_v3_its_acpi_init. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c | 36 +++-

[Xen-devel] [PATCH v2 0/5] ARM: ACPI: ITS: Add ITS Support for ACPI hardware domain

From: Manish Jaggi This patch is split into 5 patches. First two add support for updating host_its_list from ACPI MADT table. The rest patches provide support to update the hardware domain MADT table with ITS information. Changes since v1: - split patches into smaller ones -

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On 08/11/2017 05:45 AM, Wei Liu wrote: On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: On 08/08/2017 09:09 AM, Wei Liu wrote: Ian and Stefano Oleksandr discovered that the p9fs array in libxl_domain_config is name p9 instead of p9s. This causes problem for his work to rework

[Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH implementation of iommu_inclusive_mapping

On certain Intel systems, as far as I can tell almost all pre-Haswell ones, trying to boot a PVH Dom0 will freeze the box completely, up to the point that not even the watchdog works. The freeze happens exactly when enabling the DMA remapping in the IOMMU, the last line seen is: (XEN)

[Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

They are emulated by Xen, so they must not be mapped into Dom0 p2m. Introduce a helper function to add the MMCFG areas to the list of denied iomem regions for PVH Dom0. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On Fri, 11 Aug 2017, Wei Liu wrote: > On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: > > On 08/08/2017 09:09 AM, Wei Liu wrote: > > > Ian and Stefano > > > > > > Oleksandr discovered that the p9fs array in libxl_domain_config is name > > > p9 instead of p9s. This causes problem for

[Xen-devel] [xen-unstable test] 112588: regressions - trouble: blocked/broken/fail/pass

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

[Xen-devel] [PATCH 11/11] xen/arm: Limit the scope of cpregs.h

Currently, cpregs.h is included in pretty much every files even for arm64. However, the only use for arm64 is when emulating co-processors. For arm32, cpregs.h rely on the presence of processor.h (define *_SYSREG helpers). So move the inclusion in asm-arm/arm32/processor.h. cpregs.h will also be

[Xen-devel] [PATCH 02/11] xen/arm: domain: Re-order the includes alphabetically

Signed-off-by: Julien Grall --- xen/arch/arm/domain.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 2dc8b0ab5a..1d835d321d 100644 --- a/xen/arch/arm/domain.c +++

[Xen-devel] [PATCH 09/11] xen/arm: Move co-processor emulation outside of traps.c

The co-processor emulation is quite big and pretty much standalone. Move it in a separate file to shrink down the size of traps.c. At the same time remove unused cpregs.h. No functional change. Signed-off-by: Julien Grall --- xen/arch/arm/Makefile | 1 +

[Xen-devel] [PATCH 07/11] xen/arm: traps: Export a bunch of helpers to handle emulation

A follow-up patch will move some parts of traps.c in separate files. The will require to use helpers that are currently statically defined. Export the following helpers: - inject_undef64_exception - inject_undef_exception - check_conditional_instr - advance_pc - handle_raz_wi

[Xen-devel] [PATCH 03/11] xen/arm: traps: Re-order the includes alphabetically

Signed-off-by: Julien Grall --- xen/arch/arm/traps.c | 42 ++ 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index c07999b518..ca9bef712c 100644 --- a/xen/arch/arm/traps.c

[Xen-devel] [PATCH 10/11] xen/arm: Move sysregs.h in arm64 sub-directory

sysregs.h contains only code protected by #ifdef CONFIG_ARM_64. Move it in arm64 sub-directory to reflect that and remove the #ifdef. At the same time, fixup the guards. Signed-off-by: Julien Grall --- xen/include/asm-arm/arm64/processor.h | 2 ++

[Xen-devel] [PATCH 01/11] xen/grant_table: Include mm.h in xen/grant_table.h

While re-ordering the include alphabetically in arch/arm/domain.c, I got a complitation error because grant_table.h is using gfn_t before been defined: In file included from domain.c:14:0: xen/xen/include/xen/grant_table.h:153:29: error: unknown type name ‘gfn_t’

[Xen-devel] [PATCH 05/11] xen/arm: vtimer: Re-order the includes alphabetically

Signed-off-by: Julien Grall --- xen/arch/arm/vtimer.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c index 32ac1279ae..9c7e8f441c 100644 --- a/xen/arch/arm/vtimer.c +++ b/xen/arch/arm/vtimer.c @@

[Xen-devel] [PATCH 08/11] xen/arm: Move sysreg emulation outside of traps.c

The sysreg emulation is 64-bit specific and surrounded by #ifdef. Move them in a separate file arm/arm64/vsysreg.c to shrink down a bit traps.c No functional change. Signed-off-by: Julien Grall --- xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/vsysreg.c

[Xen-devel] [PATCH v2 4/4] x86/dom0: re-order DMA remapping enabling for PVH Dom0

Make sure the reserved regions are setup before enabling the DMA remapping in the IOMMU, by calling dom0_setup_permissions before iommu_hwdom_init. Also, in order to workaround IOMMU issues seen on pre-Haswell Intel hardware, as described in patch "introduce a PVH implementation of

[Xen-devel] [PATCH v2 0/4] x86/pvh: implement iommu_inclusive_mapping for PVH Dom0

Hello, Currently iommu_inclusive_mapping is not working for PVH Dom0, this patch series allows using it for a PVH Dom0, which seems to be required in order to boot on older boxes. Git branch can be found at: git://xenbits.xen.org/people/royger/xen.git iommu_inclusive_v2 Thanks, Roger.

[Xen-devel] [PATCH v2 2/4] x86/dom0: prevent PVH Dom0 from mapping read-only the IO APIC area

This is emulated by Xen and must not be mapped into PVH Dom0 p2m. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/dom0_build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [Xen-devel] [PATCH V2 2/3] xen-pt: bind/unbind interrupt remapping format MSI

On Wed, Aug 09, 2017 at 04:51:21PM -0400, Lan Tianyu wrote: > From: Chao Gao > > If a vIOMMU is exposed to guest, guest will configure the msi to remapping > format. The original code isn't suitable to the new format. A new pair > bind/unbind interfaces are added for this

Re: [Xen-devel] Regarding changing memory for DOM0

Hi all, Thank you for the reply. I checked with xen version 4.9, Still the error for the filesystem persists. What seems to be the problem?. I am attaching the log for the above error and also the dts file I am using. Regards, George NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.9

[Xen-devel] [qemu-mainline baseline-only test] 71961: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71961 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71961/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 20

[Xen-devel] [distros-debian-jessie test] 71962: tolerable trouble: blocked/broken/pass

flight 71962 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71962/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a build-arm64

Re: [Xen-devel] Regarding changing memory for DOM0

Hello George, On 11.08.17 10:16, George John wrote: I checked with xen version 4.9, Still the error for the filesystem persists. What seems to be the problem?. I am attaching the log for the above error and also the dts file I am using. I've looked through the log and it is the same as on my

[Xen-devel] [ovmf baseline-only test] 71963: all pass

This run is configured for baseline tests only. flight 71963 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71963/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7 baseline

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote: > Aah, okay. Now I understand the problem. The TLB isn't the issue but the > IPI is serving two purposes here: TLB flushing (which is allowed to > happen at any time) and serialization regarding access to critical pages > (which seems

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 14:54, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote: >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the >> IPI is serving two purposes here: TLB flushing (which is allowed to >> happen at any time) and serialization

[Xen-devel] [PATCH v2] x86: check for allocation errors in modify_xen_mappings()

Reported-by: Julien Grall Signed-off-by: Jan Beulich --- v2: Comment the pl2e related ASSERT(). --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5903,7 +5903,7 @@ int modify_xen_mappings(unsigned long s, { l3_pgentry_t *pl3e =

Re: [Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

On 10.08.17 00:22, Julien Grall wrote: On 09/08/2017 22:06, Volodymyr Babchuk wrote: Hi Julien, On 09.08.17 23:34, Julien Grall wrote: On 09/08/2017 20:44, Volodymyr Babchuk wrote: On ARMv8, one of conditional exceptions (SMC that originates from aarch32 state) have extra field in

Re: [Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

On 11/08/17 14:26, Volodymyr Babchuk wrote: On 10.08.17 00:22, Julien Grall wrote: On 09/08/2017 22:06, Volodymyr Babchuk wrote: Hi Julien, On 09.08.17 23:34, Julien Grall wrote: On 09/08/2017 20:44, Volodymyr Babchuk wrote: On ARMv8, one of conditional exceptions (SMC that

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

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

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote: > Wait - the TLB can be cleared at any time, as Andrew was pointing out. > No cpu can rely on an address being accessible just because IF is being > cleared. All that matters is the existing and valid page table entry. > > So clearing

Re: [Xen-devel] [RFC v2 13/23] x86/power/64: Adapt assembly for PIE support

On Thu 2017-08-10 10:26:05, Thomas Garnier wrote: > 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. > >

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 14:35, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote: >> Wait - the TLB can be cleared at any time, as Andrew was pointing out. >> No cpu can rely on an address being accessible just because IF is being >> cleared. All that matters is the

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

Hi Julien, On 11.08.17 00:09, Julien Grall wrote: On 10/08/2017 21:09, Volodymyr Babchuk wrote: Hi, On 10.08.17 21:18, Julien Grall wrote: Hi, On 10/08/17 18:40, Volodymyr Babchuk wrote: On 10.08.17 19:11, Julien Grall wrote: On 10/08/17 16:33, Volodymyr Babchuk wrote: Hi Julien,

Re: [Xen-devel] [PATCH v2 3/3] x86/p2m-pt: pass level instead of page type to p2m_next_level()

>>> On 27.07.17 at 18:50, wrote: > On Wed, Jul 5, 2017 at 11:06 AM, Jan Beulich wrote: >> This in turn calls for p2m_alloc_ptp() also being passed the numeric >> level. >> >> Signed-off-by: Jan Beulich >> --- >> v2: New. >> ---

[Xen-devel] [qemu-mainline test] 112581: regressions - trouble: blocked/broken/fail/pass

flight 112581 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112581/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 112557

[Xen-devel] [PATCH v3 2/3] x86/p2m: make p2m_alloc_ptp() return an MFN

None of the callers really needs the struct page_info pointer. Signed-off-by: Jan Beulich Acked-by: George Dunlap --- v3: Re-base over changes to patch 1. v2: Re-base over changes to patch 1. --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c

[Xen-devel] Alloc Page from fixed physical memory range

Hello All, Is there any way in linux e.g using device tree, to give a driver a fixed physical memory range to alloc pages from? All pages are allocated from kernel memory assigned using memory node in device tree. Is there any way to create a memory node and assign it to driver so that buddy

Re: [Xen-devel] [PATCH v4 9/9] vpci/msix: add MSI-X handlers

On Fri, Aug 11, 2017 at 04:01:05AM -0600, Jan Beulich wrote: > >>> On 10.08.17 at 19:04, wrote: > > On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote: > >> >>> Roger Pau Monne 06/30/17 5:01 PM >>> > >> >@@ -113,6 +148,35 @@ static int

Re: [Xen-devel] [RFC] xen/arm: Suspend to RAM Support in Xen for ARM

Hi Andrii, Thank you very much for your feedback, please see my answers below. On Thu, Aug 10, 2017 at 1:13 PM, Andrii Anisov wrote: > Dear Mirela, > > Please see my comments below: > > > > On 09.08.17 20:43, Mirela Simonovic wrote: > >> This document contains our draft

Re: [Xen-devel] [PATCH v2 1/3] x86/p2m-pt: simplify p2m_next_level()

>>> On 27.07.17 at 18:19, wrote: > On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote: >> Calculate entry PFN and flags just once. Convert the two successive >> main if()-s to and if/elf-if chain. Restrict variable scope where >> reasonable. Take

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > Changes: > - v2: >- Add support for global stack cookie while compiler default to fs without > mcmodel=kernel >- Change patch 7 to correctly jump out of the identity mapping on kexec > load > preserve. > > These patches make

Re: [Xen-devel] [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

* Juergen Gross wrote: > On 08/08/17 16:00, Boris Ostrovsky wrote: > > On 08/08/2017 02:46 AM, Juergen Gross wrote: > >> On 28/07/17 12:23, Juergen Gross wrote: > >>> This patch series fixes a regression introduced in 4.13-rc1: A Xen > >>> HVM guest with KASLR enabled wouldn't

[Xen-devel] [PATCH v3 0/3] x86/p2m: some code simplification

1: simplify p2m_next_level() 2: make p2m_alloc_ptp() return an MFN 3: pass level instead of page type to p2m_next_level() Signed-off-by: Jan Beulich See individual patches for change info. ___ Xen-devel mailing list

[Xen-devel] [PATCH v3 1/3] x86/p2m-pt: simplify p2m_next_level()

Calculate entry PFN and flags just once. Convert the two successive main if()-s to and if/else-if chain. Restrict variable scope where reasonable. Take the opportunity and also make the induction variable unsigned. This at once fixes excessive permissions granted in the 2M PTEs resulting from

[Xen-devel] [PATCH v3 3/3] x86/p2m-pt: pass level instead of page type to p2m_next_level()

This in turn calls for p2m_alloc_ptp() also being passed the numeric level. Signed-off-by: Jan Beulich Reviewed-by: George Dunlap --- v2: New. --- Question is whether passing the level to p2m_alloc_ptp() is really all that useful: p2m-ept.c's passes

[Xen-devel] [PATCH] x86/config: Fix stale documentation concerning virtual layout

The hypercall argument translation area lives in the per-domain mappings in PML4 slot 260. Nothing currently resides in the lower canonical half above the 4GB boundary in a 32bit PV guest. Signed-off-by: Andrew Cooper --- CC: Jan Beulich ---

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 03:07:29PM +0200, Juergen Gross wrote: > On 11/08/17 14:54, Peter Zijlstra wrote: > > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote: > >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the > >> IPI is serving two purposes here: TLB

Re: [Xen-devel] [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

On 08/08/17 16:00, Boris Ostrovsky wrote: > On 08/08/2017 02:46 AM, Juergen Gross wrote: >> On 28/07/17 12:23, Juergen Gross wrote: >>> This patch series fixes a regression introduced in 4.13-rc1: A Xen >>> HVM guest with KASLR enabled wouldn't boot any longer due to the usage >>> of __va() before

Re: [Xen-devel] [PATCH 0/4] ARM: ACPI: ITS: Add ITS Support for ACPI hardware domain

Hi, On 11/08/17 05:54, Manish Jaggi wrote: On 8/10/2017 6:44 PM, Julien Grall wrote: On 08/10/2017 02:00 PM, Manish Jaggi wrote: HI Julien, On 8/10/2017 5:43 PM, Julien Grall wrote: On 10/08/17 13:00, Manish Jaggi wrote: Hi Julien, On 8/10/2017 4:58 PM, Julien Grall wrote: On

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

Hi Volodymyr, On 10/08/17 22:09, Julien Grall wrote: We can stick to XEN-only approach, like XENFEAT_* or "xen,smccc" in DT. But is this right? Answering to this question after some thoughts and discussion around. The generic approach is indeed the best solution, however I am afraid it

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote: > Peter Zijlstra writes: > > > On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote: > > > >> > > Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote > >> > > TLB flush > >> > >> >

[Xen-devel] [libvirt test] 112586: tolerable trouble: blocked/broken/pass - PUSHED

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

Re: [Xen-devel] [PATCH v4 9/9] vpci/msix: add MSI-X handlers

>>> On 10.08.17 at 19:04, wrote: > On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote: >> >>> Roger Pau Monne 06/30/17 5:01 PM >>> >> >@@ -113,6 +148,35 @@ static int vpci_modify_bar(struct domain *d, const >> >struct vpci_bar *bar, >> >if (

Re: [Xen-devel] [PATCH v2] xen: remove struct domain and vcpu declarations from types.h

>>> On 10.08.17 at 19:22, wrote: > --- a/xen/include/asm-x86/xenoprof.h > +++ b/xen/include/asm-x86/xenoprof.h > @@ -68,6 +68,8 @@ void passive_domain_destroy(struct vcpu *v); > > #else > > +struct vcpu; There already is a forward declaration in this header - I'd

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 11:56, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote: >>> >> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 12:05:45PM +0100, Andrew Cooper wrote: > >> Oh, I see your concern. Hyper-V, however, is not the first x86 > >> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this > >> too. Briefly looking at xen_flush_tlb_others() I don't see anything > >> special, do we

Re: [Xen-devel] [PATCH v4 9/9] vpci/msix: add MSI-X handlers

>>> On 11.08.17 at 12:11, wrote: > On Fri, Aug 11, 2017 at 04:01:05AM -0600, Jan Beulich wrote: >> >>> On 10.08.17 at 19:04, wrote: >> > On Wed, Aug 02, 2017 at 09:07:54AM -0600, Jan Beulich wrote: >> >> >>> Roger Pau Monne

Re: [Xen-devel] [PATCH v2] xen: remove struct domain and vcpu declarations from types.h

Hi Wei, On 10/08/17 18:22, Wei Liu wrote: They don't belong there. Removing them causes build errors in several places. Add the forward declarations in those places. Signed-off-by: Wei Liu For ARM: reviewed-by: Julien Grall Cheers, --- Cc:

Re: [Xen-devel] [PATCH v2] xen: remove struct domain and vcpu declarations from types.h

On Fri, Aug 11, 2017 at 04:15:59AM -0600, Jan Beulich wrote: > >>> On 10.08.17 at 19:22, wrote: > > --- a/xen/include/asm-x86/xenoprof.h > > +++ b/xen/include/asm-x86/xenoprof.h > > @@ -68,6 +68,8 @@ void passive_domain_destroy(struct vcpu *v); > > > > #else > > > >

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

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

[Xen-devel] [linux-3.18 test] 112579: trouble: blocked/broken/fail/pass

flight 112579 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112579/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: > On 08/08/2017 09:09 AM, Wei Liu wrote: > > Ian and Stefano > > > > Oleksandr discovered that the p9fs array in libxl_domain_config is name > > p9 instead of p9s. This causes problem for his work to rework device > > framework. > > > >

Re: [Xen-devel] [PATCH v2 1/3] x86/p2m-pt: simplify p2m_next_level()

>>> On 27.07.17 at 18:19, wrote: > On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote: >> Calculate entry PFN and flags just once. Convert the two successive >> main if()-s to and if/elf-if chain. Restrict variable scope where >> reasonable. Take

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 12:56, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote: >>> >> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall

[Xen-devel] [linux-linus test] 112577: regressions - trouble: blocked/broken/fail/pass

flight 112577 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112577/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On Fri, Aug 11, 2017 at 12:37:04PM -0600, Jim Fehlig wrote: > On 08/11/2017 05:45 AM, Wei Liu wrote: > > On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: > > > On 08/08/2017 09:09 AM, Wei Liu wrote: > > > > Ian and Stefano > > > > > > > > Oleksandr discovered that the p9fs array in

Re: [Xen-devel] [PATCH v3 02/13] xen/pvcalls: implement frontend disconnect

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > Introduce a data structure named pvcalls_bedata. It contains pointers to > the command ring, the event channel, a list of active sockets and a list > of passive sockets. Lists accesses are protected by a spin_lock. > > Introduce a waitqueue to

Re: [Xen-devel] [PATCH v3 03/13] xen/pvcalls: connect to the backend

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > Implement the probe function for the pvcalls frontend. Read the > supported versions, max-page-order and function-calls nodes from > xenstore. > > Only one frontend<->backend connection is supported at any given time > for a guest. Store the

[Xen-devel] [linux-3.18 test] 112595: trouble: blocked/broken/fail/pass

flight 112595 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112595/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On 08/11/2017 02:27 PM, Wei Liu wrote: On Fri, Aug 11, 2017 at 12:37:04PM -0600, Jim Fehlig wrote: On 08/11/2017 05:45 AM, Wei Liu wrote: On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: On 08/08/2017 09:09 AM, Wei Liu wrote: Ian and Stefano Oleksandr discovered that the p9fs

Re: [Xen-devel] [PATCH v3 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > Introduce a xenbus frontend for the pvcalls protocol, as defined by > https://xenbits.xen.org/docs/unstable/misc/pvcalls.html. > > This patch only adds the stubs, the code will be added by the following > patches. > > Signed-off-by: Stefano

[Xen-devel] [ovmf baseline-only test] 71966: all pass

This run is configured for baseline tests only. flight 71966 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71966/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf bee7fe0ef950e2966cbdcd753be326f8a3c782f3 baseline

[Xen-devel] [linux-next test] 112593: regressions - trouble: blocked/broken/fail/pass

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

[Xen-devel] [qemu-mainline test] 112598: regressions - trouble: blocked/broken/fail/pass

flight 112598 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112598/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 112557

[Xen-devel] [linux-4.9 test] 112599: regressions - trouble: blocked/broken/fail/pass

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

[Xen-devel] [PATCH v2 01/12] [x86|arm]: remove code duplication

There is a substantial amount of code duplicated between the x86 and arm implementations of mm.c:xenmem_add_to_physmap_one() for XENMAPSPACE_grant_table. Also, the code in question looks like it really should be in common/grant_table.c This patch introduces a new function in common/grant_table.c

[Xen-devel] [PATCH v2 07/12] x86/hvm/ioreq: use bool rather than bool_t

This patch changes use of bool_t to bool in the IOREQ server code. It also fixes an incorrect indentation in a continuation line. This patch is purely cosmetic. No semantic or functional change. Signed-off-by: Paul Durrant --- Cc: Jan Beulich Cc:

[Xen-devel] [PATCH v2 08/12] x86/hvm/ioreq: move is_default into struct hvm_ioreq_server

Legacy emulators use the 'default' IOREQ server which has slightly different semantics than other, explicitly created, IOREQ servers. Because of this, most of the initialization and teardown code needs to know whether the server is default or not. This is currently achieved by passing an

[Xen-devel] [PATCH v2 03/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

Certain memory resources associated with a guest are not necessarily present in the guest P2M and so are not necessarily available to be foreign-mapped by a tools domain unless they are inserted, which risks shattering a super-page mapping. This patch adds a new memory op to allow such resourced

[Xen-devel] [PATCH v2 04/12] tools/libxenforeignmemory: add support for resource mapping

A previous patch introduced a new HYPERVISOR_memory_op to acquire guest resources for direct priv-mapping. This patch adds new functionality into libxenforeignmemory to make use of a new privcmd ioctl [1] that uses the new memory op to make such resources available via mmap(2). [1]

[Xen-devel] [PATCH v2 09/12] x86/hvm/ioreq: simplify code and use consistent naming

This patch re-works much of the IOREQ server initialization and teardown code: - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called separately by outer functions. - Several functions now test the validity

[Xen-devel] [PATCH v2 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

A previous patch added support for priv-mapping guest resources directly (rather than having to foreign-map, which requires P2M modification for HVM guests). This patch makes use of the new API to seed the guest grant table unless the underlying infrastructure (i.e. privcmd) doesn't support it,

[Xen-devel] [PATCH v2 02/12] x86/mm: allow a privileged PV domain to map guest mfns

In the case where a PV domain is mapping guest resources then it needs make the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest domid, so that the passed in gmfn values are correctly treated as mfns rather than gfns present in the guest p2m. This patch removes a check which

[Xen-devel] [PATCH v2 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn

Since IOREQ servers are only relevant to HVM guests and all the names in question unequivocally refer to guest frame numbers, name them all .*gfn to avoid any confusion. This patch is purely cosmetic. No semantic or functional change. Signed-off-by: Paul Durrant --- Cc:

[Xen-devel] [PATCH v2 00/12] x86: guest resource mapping

This series introduces support for direct mapping of guest resources. The resources are: - Grant tables - IOREQ server pages Paul Durrant (12): [x86|arm]: remove code duplication x86/mm: allow a privileged PV domain to map guest mfns x86/mm: add HYPERVISOR_memory_op to acquire guest

Re: [Xen-devel] [RFC PATCH v2 09/22] ARM: vITS: protect LPI priority update with pending_irq lock

Hi Andre, On 21/07/17 20:59, Andre Przywara wrote: As the priority value is now officially a member of struct pending_irq, we need to take its lock when manipulating it via ITS commands. Make sure we take the IRQ lock after the VCPU lock when we need both. Signed-off-by: Andre Przywara

Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

On Wed, 2017-08-09 at 12:38 +0100, Tim Deegan wrote: > Hi, > Hey! :-) > At 10:01 +0200 on 27 Jul (1501149684), Dario Faggioli wrote: > > In Xen, that is impossible, and that's particularly problematic > > when system is idle (or lightly loaded) systems, as CPUs that > > are idle may never have

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

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

[Xen-devel] [PATCH 04/11] xen/arm: vgic-v3: Re-order the includes alphabetically

Signed-off-by: Julien Grall --- xen/arch/arm/vgic-v3.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c index 48c7682671..cbeac28b28 100644 --- a/xen/arch/arm/vgic-v3.c +++ b/xen/arch/arm/vgic-v3.c @@

[Xen-devel] [PATCH 06/11] xen/arm: Move arch/arm/vtimer.h to include/asm-arm/vtimer.h

It will be necessary to include vtimer.h from subdirectory making the inclusion a bit awkward. Signed-off-by: Julien Grall --- xen/arch/arm/domain.c | 2 +- xen/arch/arm/traps.c | 2 +- xen/{arch/arm => include/asm-arm}/vtimer.h |

[Xen-devel] [PATCH 00/11] xen/arm: Clean-up traps.c

Hi all, xen/arch/arm/traps.c is beginning to get very big. This series is moving out the co-processor and sysreg emulate in separate files. This will avoid to grow traps.c when adding more registers emulations (coming soon). A branch with this series has been pushed:

  1   2   >