[Xen-devel] [PATCH] dom_ids array implementation.

Hi, Jan, Please help to review this patch. Thank you! Signed-off-by: Yi Sun --- xen/arch/x86/psr.c | 135 ++--- 1 file changed, 55 insertions(+), 80 deletions(-) diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c

[Xen-devel] [PATCH 00/10] block: assorted cleanup for bio splitting and cloning.

This series contains more work towards getting rid of the bioset work queues and generally improving the splitting and cloning of bios. The first three patches are similar to ones that I sent previously. They have been rebased on the current block for-next tree and improved a little.

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

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

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

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

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

flight 107541 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/107541/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254

Re: [Xen-devel] [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND

On 20/04/17 01:10, Stefano Stabellini wrote: > Juergen, I have committed this patch to for-linus-4.12 and linux-next, I > hope that's OK. Sure. Juergen > > Og Wed, 19 Apr 2017, Stefano Stabellini wrote: >> On Wed, 19 Apr 2017, Arnd Bergmann wrote: >>> All Xen frontends need to select this

Re: [Xen-devel] [PATCH 2/6] xen/arm: domain_build: Inherit GIC's interrupt-parent from host device tree

> Authored-by: Kyle Temkin We use "From: " for the author and it is different here. So who wrote this code? It was a team effort, but my intention was to indicate him as the primary author. I'll set him as From in v2. Thanks!

[Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) -> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode and APIC ID are preserved when handling INIT signal and a reset places APIC to xAPIC mode and APIC base address to 0xFEE0h (this part is in "Local APIC"

Re: [Xen-devel] [PATCH v2] x86/vlapic: Don't reset APIC ID when handling INIT signal

On Wed, Apr 19, 2017 at 03:41:41PM +0800, Chao Gao wrote: >>> -vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE | >>> -APIC_DEFAULT_PHYS_BASE); >>> +vlapic->hw.apic_base_msr |= APIC_DEFAULT_PHYS_BASE; >> >>Perhaps better move this ahead of the call to

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

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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

On 17-04-19 03:00:29, Jan Beulich wrote: > >>> On 19.04.17 at 10:22, wrote: > > On 17-04-18 05:46:43, Jan Beulich wrote: > >> >>> On 18.04.17 at 12:55, wrote: > >> > I made a test patch based on v10 and attached it in mail. Could you > >> >

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

On 04/19/2017 05:36 PM, Alistair Francis wrote: > On Wed, Apr 19, 2017 at 3:22 PM, Eric Blake wrote: >> Libvirt would like to be able to distinguish between a SHUTDOWN >> event triggered solely by guest request and one triggered by a >> SIGTERM or other action on the host.

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

flight 107539 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107539/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 4 host-ping-check-native fail pass in 107528 Regressions which are regarded

Re: [Xen-devel] raisin and minios stubdom

On Mon, 10 Apr 2017, Juergen Gross wrote: > On 07/04/17 20:54, Géza Gémes wrote: > > > > On 01/04/17 08:19, Géza Gémes wrote: > > > > > > > > > 2017. márc. 31. 16:15 ezt írta ("Juergen Gross" > > > >

Re: [Xen-devel] Outreachy project - Xen Code Review Dashboard

Hi Jesus, I have a version of the task running, I'd love if you could take a look and let me know if there are any changes you'd like to see. It's at https://github.com/heatherbooker/xen-outreachy It gets the mailboxes, analyzes them using Perceval and an implementation of the well known jwz's

[Xen-devel] [linux-arm-xen test] 107537: regressions - FAIL

flight 107537 linux-arm-xen real [real] http://logs.test-lab.xenproject.org/osstest/logs/107537/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 107176 Regressions

Re: [Xen-devel] [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND

Juergen, I have committed this patch to for-linus-4.12 and linux-next, I hope that's OK. Og Wed, 19 Apr 2017, Stefano Stabellini wrote: > On Wed, 19 Apr 2017, Arnd Bergmann wrote: > > All Xen frontends need to select this symbol to avoid a link error: > > > > net/built-in.o: In function

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

On Wed, 19 Apr 2017, Paul Durrant wrote: > > -Original Message- > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: 18 April 2017 18:41 > > To: Paul Durrant > > Cc: 'Stefano Stabellini' ; qemu-de...@nongnu.org; > >

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

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

On Wed, Apr 19, 2017 at 3:22 PM, Eric Blake wrote: > Libvirt would like to be able to distinguish between a SHUTDOWN > event triggered solely by guest request and one triggered by a > SIGTERM or other action on the host. qemu_kill_report() is > already able to tell whether a

[Xen-devel] [PATCH v2] event: Add source information to SHUTDOWN

Libvirt would like to be able to distinguish between a SHUTDOWN event triggered solely by guest request and one triggered by a SIGTERM or other action on the host. qemu_kill_report() is already able to tell whether a shutdown was triggered by a host signal (but NOT by a host UI event, such as

Re: [Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

On Wed, 19 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 19/04/2017 22:01, Stefano Stabellini wrote: > > On Wed, 19 Apr 2017, Julien Grall wrote: > > > Currently, Xen is assuming the FDT will always fit in a 2MB section. > > > Recently, I noticed an early crash on Xen when using GRUB with

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

On 19/04/2017 22:12, Julien Grall wrote: > Would you be fine with code motion for Xen 4.9? The only important question is whether the patch/series is suitable material for 4.9. By the looks of this series, it most certainly is (and at the end of the day, you have final say on this matter).

Re: [Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

Hi Stefano, On 19/04/2017 22:01, Stefano Stabellini wrote: On Wed, 19 Apr 2017, Julien Grall wrote: Currently, Xen is assuming the FDT will always fit in a 2MB section. Recently, I noticed an early crash on Xen when using GRUB with the following call trace: (XEN) Hypervisor Trap.

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

On Wed, 19 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 19/04/2017 22:01, Stefano Stabellini wrote: > > On Wed, 19 Apr 2017, Julien Grall wrote: > > > The FDT will not be accessed before start_xen (begining of C code) is > > > called and it will be easier to maintain as the code could be

Re: [Xen-devel] [PATCH for-4.9 3/4] xen/arm: Check if the FDT passed by the bootloader is valid

Hi Stefano, On 19/04/2017 22:01, Stefano Stabellini wrote: On Wed, 19 Apr 2017, Julien Grall wrote: There is currently no sanity check on the FDT passed by the bootloader. Whilst they are stricly not necessary, it will avoid us to spend hours to try to find out why it does not work. >From the

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

Hi Stefano, On 19/04/2017 22:01, Stefano Stabellini wrote: On Wed, 19 Apr 2017, Julien Grall wrote: The FDT will not be accessed before start_xen (begining of C code) is called and it will be easier to maintain as the code could be common between AArch32 and AArch64. A new function

Re: [Xen-devel] [PATCH for-4.9 1/4] xen/arm: Add BOOT_FDT_VIRT_END and BOOT_FDT_SLOT_SIZE

On Wed, 19 Apr 2017, Julien Grall wrote: > The 2 new defines will help to avoid hardcoding the size and the end of > the slot in the code. > > The newlines are added for clarity. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini >

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

On Wed, 19 Apr 2017, Julien Grall wrote: > The FDT will not be accessed before start_xen (begining of C code) is > called and it will be easier to maintain as the code could be common > between AArch32 and AArch64. > > A new function early_fdt_map is introduced to map the FDT in the boot > page

Re: [Xen-devel] [PATCH for-4.9 3/4] xen/arm: Check if the FDT passed by the bootloader is valid

On Wed, 19 Apr 2017, Julien Grall wrote: > There is currently no sanity check on the FDT passed by the bootloader. > Whilst they are stricly not necessary, it will avoid us to spend hours > to try to find out why it does not work. > > >From the booting documentation for AArch32 [1] and AArch64

Re: [Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

On Wed, 19 Apr 2017, Julien Grall wrote: > Currently, Xen is assuming the FDT will always fit in a 2MB section. > Recently, I noticed an early crash on Xen when using GRUB with the > following call trace: > > (XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6 > (XEN) CPU0: Unexpected

[Xen-devel] [PATCH v4 0/2] kexec: Use hypercall_create_continuation to protect KEXEC ops

During testing (using the script below) we found that multiple invocations of kexec of unload/load are not safe. This does not exist in classic Xen kernels in which the kexec-tools did the kexec via Linux kernel syscall (which in turn made the hypercall), as the Linux code has a mutex_trylock

[Xen-devel] [PATCH v4 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

When we concurrently try to unload and load crash images we eventually get: Xen call trace: [] machine_kexec_add_page+0x3a0/0x3fa [] machine_kexec_load+0xdb/0x107 [] kexec.c#kexec_load_slot+0x11/0x42 [] kexec.c#kexec_load+0x119/0x150 [] kexec.c#do_kexec_op_internal+0xab/0xcf

[Xen-devel] [PATCH v4 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

The spinlock in kexec_swap_images() was removed as this function is only reachable on the kexec hypercall, which is now protected at the top-level in do_kexec_op_internal(), thus the local spinlock is no longer necessary. Per recommendation from Jan Beulich and Andrew Cooper, I left an ASSERT in

[Xen-devel] [xen-unstable baseline-only test] 71205: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71205 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71205/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumprun-amd64 16

Re: [Xen-devel] [PATCH 1/6] xen/arm: platforms: Add earlyprintk and serial support for Tegra boards.

Will split patches & fix for v2, thanks! ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

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

flight 107547 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107547/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 host-build-prep fail REGR. vs. 107540 Tests which

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

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

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

On Wed, Apr 19, 2017 at 08:37:38PM +0100, Matt Fleming wrote: > On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote: > > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > > > > > Please, let's keep the Xen knowledge

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote: > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > > > rather than spreading it further. > >

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > > rather than spreading it further. > > > > IMO, given reset_system is a *mandatory* function, the

Re: [Xen-devel] [PATCH 07/10] xen/arm: vpl011: Add a new console type to domain structure in xenconsole

On Mon, 3 Apr 2017, Bhupinder Thakur wrote: > Modify the domain structure to to make console specific fields as an array > indexed > by the console type. Two console types are defined - PV and VCON. > > Signed-off-by: Bhupinder Thakur > --- >

Re: [Xen-devel] [PATCH 06/10] xen/arm: vpl011: Add new parameters to xenstore for the virtual console

On Mon, 3 Apr 2017, Bhupinder Thakur wrote: > Add two new parameters to the xen store: > - newly allocated PFN to be used as IN/OUT ring buffer by xenconsoled > - a new event channel read from Xen using a hvm call to be used by > xenconsoled > > Signed-off-by: Bhupinder Thakur

[Xen-devel] [PATCH v5] ns16550: Add support for UART parameters to be specifed with name-value pairs

Add name=value parsing options for com1 and com2 to add flexibility in setting register values for MMIO UART devices. Maintain backward compatibility with previous positional parameter specfications. eg. com1=115200,8n1,0x3f8,4 eg. com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2 eg.

Re: [Xen-devel] [PATCH 09/10] xen/arm: vpl011: Add new virtual console to xenconsole client

On Mon, 3 Apr 2017, Bhupinder Thakur wrote: > Add a new console type VCON to connect to the virtual console. VUART is a better name here too. Please add a doc under docs/misc to document the new xenstore paths. > Signed-off-by: Bhupinder Thakur > --- >

Re: [Xen-devel] [PATCH 10/10] xen/arm: vpl011: Add a pl011 uart DT node in the guest device tree

On Mon, 3 Apr 2017, Bhupinder Thakur wrote: > The SBSA uart node format is as specified in > Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below: > > ARM SBSA defined generic UART > -- > This UART uses a subset of the PL011 registers and

[Xen-devel] [xen-unstable-smoke test] 107544: regressions - trouble: broken/fail/pass

flight 107544 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107544/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs. 107540 Tests

[Xen-devel] [linux-3.18 test] 107534: regressions - FAIL

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

Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

On Fri, 14 Apr 2017, Bhupinder Thakur wrote: > Hi Stefano, > > On 12 April 2017 at 03:37, Stefano Stabellini wrote: > > On Tue, 11 Apr 2017, Bhupinder Thakur wrote: > >> Hi, > >> > >> Kindly let me know if my understanding is correct. > >> > >> Using a domctl API will

Re: [Xen-devel] [PATCH 01/10] xen/arm: vpl011: Add pl011 uart emulation in Xen

On Wed, 19 Apr 2017, Bhupinder Thakur wrote: > Hi Stefano, > > Thanks for your comments. > > On 19 April 2017 at 05:45, Stefano Stabellini wrote: > >> +static void vpl011_read_data(struct domain *d, uint8_t *data) > >> +{ > >> +unsigned long flags; > >> +struct

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On Wed, 19 Apr 2017, Juergen Gross wrote: > On 19/04/17 19:25, Stefano Stabellini wrote: > > Hello Russell, > > > > Can I have your acked-by on the following fix (original patch is > > 1492117462-19886-1-git-send-email-sstabell...@kernel.org)? > > Stefano, through which tree should this go? ARM

Re: [Xen-devel] [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl

Hi Oleksandr, Please CC the appropriate maintainers for all the components you modify. On 15/03/17 20:05, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This flag is intended to let Xen know that the guest has devices which will most likely be used for

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

On 19/04/17 19:25, Stefano Stabellini wrote: > Hello Russell, > > Can I have your acked-by on the following fix (original patch is > 1492117462-19886-1-git-send-email-sstabell...@kernel.org)? Stefano, through which tree should this go? ARM or Xen or other? Juergen > > Thanks, > > Stefano >

Re: [Xen-devel] [RFC PATCH 8/9] iommu: Split iommu_hwdom_init() into arch specific parts

Hi, Sorry for the late answer. On 23/03/17 12:40, Oleksandr Tyshchenko wrote: On Thu, Mar 23, 2017 at 11:08 AM, Jan Beulich wrote: On 22.03.17 at 19:40, wrote: On Wed, Mar 22, 2017 at 5:54 PM, Jan Beulich wrote: On 15.03.17 at

[Xen-devel] [libvirt test] 107536: tolerable FAIL - PUSHED

flight 107536 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/107536/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107442 test-armhf-armhf-libvirt-raw 12

Re: [Xen-devel] [RFC PATCH 4/9] xen/arm: p2m: Update IOMMU mapping whenever possible if page table is not shared

Hi Oleksandr, On 15/03/17 20:05, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Update IOMMU mapping if the IOMMU doesn't share page table with the CPU. The best place to do so on ARM is p2m_set_entry(). Use mfn as an indicator of the required action. If

[Xen-devel] [RFC PATCH v4] xen: credit2: provide custom option to create runqueue

The patch introduces a new, very flexible way of arranging runqueues in Credit2. It allows to specify, explicitly and precisely, what pCPUs should belong to which runqueue. Signed-off-by: Praveen Kumar --- docs/misc/xen-command-line.markdown | 10 ++-

[Xen-devel] [linux-4.9 test] 107532: regressions - FAIL

flight 107532 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/107532/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358 Tests which are

Re: [Xen-devel] [RFC PATCH 2/9] iommu: Add ability to map/unmap the number of pages

Hi Oleksandr, On 15/03/17 20:05, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Extend the IOMMU code with new APIs and platform callbacks. These new map_pages/unmap_pages API do almost the same thing as existing map_page/unmap_page ones except the

Re: [Xen-devel] [RFC PATCH 3/9] xen/arm: p2m: Add helper to convert p2m type to IOMMU flags

Hi Oleksandr, On 15/03/17 20:05, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko The helper has the same purpose as existing for x86 one. It is used for choosing IOMMU mapping attribute according to the memory type. Signed-off-by: Oleksandr Tyshchenko

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

Hello Russell, Can I have your acked-by on the following fix (original patch is 1492117462-19886-1-git-send-email-sstabell...@kernel.org)? Thanks, Stefano On Tue, 18 Apr 2017, Catalin Marinas wrote: > On Thu, Apr 13, 2017 at 02:04:21PM -0700, Stefano Stabellini wrote: > > The following

Re: [Xen-devel] [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND

On Wed, 19 Apr 2017, Arnd Bergmann wrote: > All Xen frontends need to select this symbol to avoid a link error: > > net/built-in.o: In function `p9_trans_xen_init': > :(.text+0x149e9c): undefined reference to `__xenbus_register_frontend' > > Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen

Re: [Xen-devel] [PATCH v3 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

On Wed, Apr 19, 2017 at 10:19:44AM -0600, Jan Beulich wrote: > >>> On 19.04.17 at 17:54, wrote: > > On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVolder wrote: > >> @@ -1193,6 +1194,9 @@ static int do_kexec_op_internal(unsigned long op, > >> if ( ret ) > >>

[Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

Currently, Xen is assuming the FDT will always fit in a 2MB section. Recently, I noticed an early crash on Xen when using GRUB with the following call trace: (XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6 (XEN) CPU0: Unexpected Trap: Hypervisor (XEN) [ Xen-4.9-unstable arm64

[Xen-devel] [PATCH for-4.9 1/4] xen/arm: Add BOOT_FDT_VIRT_END and BOOT_FDT_SLOT_SIZE

The 2 new defines will help to avoid hardcoding the size and the end of the slot in the code. The newlines are added for clarity. Signed-off-by: Julien Grall --- xen/include/asm-arm/config.h | 4 1 file changed, 4 insertions(+) diff --git

[Xen-devel] [PATCH for-4.9 3/4] xen/arm: Check if the FDT passed by the bootloader is valid

There is currently no sanity check on the FDT passed by the bootloader. Whilst they are stricly not necessary, it will avoid us to spend hours to try to find out why it does not work. From the booting documentation for AArch32 [1] and AArch64 [2] must : - be placed on 8-byte boundary -

[Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

The FDT will not be accessed before start_xen (begining of C code) is called and it will be easier to maintain as the code could be common between AArch32 and AArch64. A new function early_fdt_map is introduced to map the FDT in the boot page table. Note that create_mapping will flush the TLBs

[Xen-devel] [PATCH for-4.9 0/4] xen/arm: Properly map the FDT in the boot page table

Hi, Whilst doing some testing on Juno using GRUB, I noticed random early crash depending ([1]) on the binaries I was using. This is because Xen is assuming that the FDT will always fit in a 2MB superpage whilst the boot documentation allow the FDT to cross a 2MB boundary. The first patch move

[Xen-devel] [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND

All Xen frontends need to select this symbol to avoid a link error: net/built-in.o: In function `p9_trans_xen_init': :(.text+0x149e9c): undefined reference to `__xenbus_register_frontend' Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver") Signed-off-by: Arnd Bergmann

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

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

Re: [Xen-devel] [PATCH] x86/hvm: Corrections and improvements to unhandled vmexit logging

On 04/19/2017 11:58 AM, Andrew Cooper wrote: > * Use gprintk rather than gdprintk. These logging messages shouldn't >disappear in release builds, as they usually happen immediately before a >domain crash. Raise them from WARNING to ERR. > * Format the vmexit reason in the same base as

Re: [Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

On 04/19/2017 11:21 AM, Jan Beulich wrote: On 19.04.17 at 17:47, wrote: @@ -832,7 +831,7 @@ static int kexec_swap_images(int type, struct kexec_image *new, if ( kexec_load_get_bits(type, , ) ) return -EINVAL; -spin_lock(_lock); +ASSERT(

Re: [Xen-devel] null domains after xl destroy

On 19/04/17 20:09, Juergen Gross wrote: > On 19/04/17 09:16, Roger Pau Monné wrote: >> On Wed, Apr 19, 2017 at 06:39:41AM +0200, Juergen Gross wrote: >>> On 19/04/17 03:02, Glenn Enright wrote: Thanks Juergen. I applied that, to our 4.9.23 dom0 kernel, which still shows the issue. When

Re: [Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

>>> On 19.04.17 at 17:47, wrote: > @@ -832,7 +831,7 @@ static int kexec_swap_images(int type, struct kexec_image > *new, > if ( kexec_load_get_bits(type, , ) ) > return -EINVAL; > > -spin_lock(_lock); > +ASSERT( !test_bit(KEXEC_FLAG_IN_HYPERCALL,

Re: [Xen-devel] [PATCH v3 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

>>> On 19.04.17 at 17:54, wrote: > On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVolder wrote: >> @@ -1193,6 +1194,9 @@ static int do_kexec_op_internal(unsigned long op, >> if ( ret ) >> return ret; >> >> +if (

Re: [Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

On 04/19/2017 10:47 AM, Eric DeVolder wrote: The spinlock in kexec_swap_images() was removed as this function is only reachable on the kexec hypercall, which is now protected at the top-level in do_kexec_op_internal(), thus the local spinlock is no longer necessary. Per recommendation from Jan

Re: [Xen-devel] [PATCH v3] xen, input: add xen-kbdfront module parameter for setting resolution

On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote: > Add a parameter for setting the resolution of xen-kbdfront in order to > be able to cope with a (virtual) frame buffer of arbitrary resolution. > > While at it remove the pointless second reading of parameters from > Xenstore in the

Re: [Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

On Wed, Apr 19, 2017 at 10:47:16AM -0500, Eric DeVolder wrote: > The spinlock in kexec_swap_images() was removed as > this function is only reachable on the kexec hypercall, which is > now protected at the top-level in do_kexec_op_internal(), > thus the local spinlock is no longer necessary. > >

[Xen-devel] [PATCH] x86/hvm: Corrections and improvements to unhandled vmexit logging

* Use gprintk rather than gdprintk. These logging messages shouldn't disappear in release builds, as they usually happen immediately before a domain crash. Raise them from WARNING to ERR. * Format the vmexit reason in the same base as is used in the vendor manuals (decimal for Intel,

Re: [Xen-devel] [PATCH v3 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVolder wrote: > When we concurrently try to unload and load crash > images we eventually get: > > Xen call trace: > [] machine_kexec_add_page+0x3a0/0x3fa > [] machine_kexec_load+0xdb/0x107 > [] kexec.c#kexec_load_slot+0x11/0x42 > []

Re: [Xen-devel] [PATCH v2 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

On 04/19/2017 06:48 AM, Andrew Cooper wrote: On 19/04/17 12:00, Daniel Kiper wrote: On Tue, Apr 18, 2017 at 04:48:06AM -0600, Jan Beulich wrote: On 17.04.17 at 21:09, wrote: --- a/xen/common/kexec.c +++ b/xen/common/kexec.c @@ -50,9 +50,10 @@ static cpumask_t

Re: [Xen-devel] [PATCH v2 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

On 04/19/2017 08:37 AM, Jan Beulich wrote: On 19.04.17 at 14:13, wrote: On Wed, Apr 19, 2017 at 05:20:50AM -0600, Jan Beulich wrote: On 19.04.17 at 12:56, wrote: On Tue, Apr 18, 2017 at 04:49:48AM -0600, Jan Beulich wrote: On 17.04.17 at

[Xen-devel] [PATCH v3 0/2] kexec: Use hypercall_create_continuation to protect KEXEC ops

During testing (using the script below) we found that multiple invocations of kexec of unload/load are not safe. This does not exist in classic Xen kernels in which the kexec-tools did the kexec via Linux kernel syscall (which in turn made the hypercall), as the Linux code has a mutex_trylock

[Xen-devel] [PATCH v3 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

When we concurrently try to unload and load crash images we eventually get: Xen call trace: [] machine_kexec_add_page+0x3a0/0x3fa [] machine_kexec_load+0xdb/0x107 [] kexec.c#kexec_load_slot+0x11/0x42 [] kexec.c#kexec_load+0x119/0x150 [] kexec.c#do_kexec_op_internal+0xab/0xcf

[Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

The spinlock in kexec_swap_images() was removed as this function is only reachable on the kexec hypercall, which is now protected at the top-level in do_kexec_op_internal(), thus the local spinlock is no longer necessary. Per recommendation from Jan Beulich and Andrew Cooper, I left an ASSERT in

Re: [Xen-devel] [PATCH v2 for-next v2 8/8] x86/mm: split HVM grant table code to hvm/mm.c

>>> On 03.04.17 at 13:22, wrote: > PG_external requires hardware support so the code guarded by that is HVM > only. > > Signed-off-by: Wei Liu > --- > xen/arch/x86/hvm/Makefile | 1 + > xen/arch/x86/hvm/mm.c | 85 >

Re: [Xen-devel] [PATCH v2 for-next v2 6/8] x86/mm: move two PV hypercalls from x86_64/mm.c to pv/mm.c

>>> On 03.04.17 at 13:22, wrote: > --- a/xen/arch/x86/pv/mm.c > +++ b/xen/arch/x86/pv/mm.c > @@ -4106,6 +4106,74 @@ int mmio_ro_do_page_fault(struct vcpu *v, unsigned > long addr, Considering this file is still 4k lines, I'd prefer if stuff not obviously belonging here

Re: [Xen-devel] [PATCH v2 for-next v2 5/8] x86/mm: split PV guest supporting code to pv/mm.c

>>> On 03.04.17 at 13:22, wrote: > -static s8 __read_mostly opt_mmio_relax; > +s8 __read_mostly opt_mmio_relax; > static void __init parse_mmio_relax(const char *s) The variable has exactly one use site outside of the parsing function, which means both variable and parsing

[Xen-devel] [PATCH v2 2/3] x86/pt: enable binding of GSIs to a PVH Dom0

Achieve this by expanding pt_irq_create_bind in order to support mapping interrupts of type PT_IRQ_TYPE_PCI to a PVH Dom0. GSIs bound to Dom0 are always identity bound, which means the all the fields inside of the u.pci sub-struct are ignored, and only the machine_irq is actually used in order to

[Xen-devel] [PATCH v2 1/3] x86/physdev: factor out the code to allocate and map a pirq

Move the code to allocate and map a domain pirq (either GSI or MSI) into the x86 irq code base, so that it can be used outside of the physdev ops. This change shouldn't affect the functionality of the already existing physdev ops. Signed-off-by: Roger Pau Monné --- Jan

Re: [Xen-devel] [PATCH v2 for-next v2 2/8] x86/mm: carve out create_grant_pv_mapping

>>> On 03.04.17 at 13:22, wrote: > @@ -4300,6 +4297,15 @@ int create_grant_host_mapping(uint64_t addr, unsigned > long frame, > return create_grant_va_mapping(addr, pte, current); > } > > +int create_grant_host_mapping(uint64_t addr, unsigned long frame, > +

[Xen-devel] [PATCH v2 0/3] x86/dpci: bind legacy PCI interrupts to PVHv2 Dom0

Hello, The following patches allow binding bare-metal GSIs into a PVHv2 Dom0, by snooping on the vIO APICs writes made by Dom0. This new version has reduced the number of patches from 5 to 3, first two patches introduce the necessary code to bind GSIs into a PVH Dom0, and patch 3 snoops on vIO

[Xen-devel] [PATCH v2 3/3] x86/vioapic: bind interrupts to PVH Dom0

Add the glue in order to bind the PVH Dom0 GSI from bare metal. This is done when Dom0 unmasks the vIO APIC pins, by fetching the current pin settings and setting up the PIRQ, which will then be bound to Dom0. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich

Re: [Xen-devel] [PATCH v2 for-next v2 1/8] mm: provide more grep fodders

>>> On 03.04.17 at 13:22, wrote: > Define several _* and *_x macros for better grep-ability. This also > helps indexing tool like GNU Global. > > No functional change. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH v2] x86/vlapic: Don't reset APIC ID when handling INIT signal

>>> On 19.04.17 at 09:41, wrote: > On Wed, Apr 19, 2017 at 08:17:14AM -0600, Jan Beulich wrote: > On 19.04.17 at 08:40, wrote: >>> @@ -1257,7 +1257,12 @@ void vlapic_reset(struct vlapic *vlapic) >>> } >>> vlapic_set_reg(vlapic, APIC_ICR,

Re: [Xen-devel] [PATCH v4] ns16550: Add support for UART parameters to be specifed with name-value pairs

>>> On 18.04.17 at 18:07, wrote: > --- a/xen/drivers/char/ns16550.c > +++ b/xen/drivers/char/ns16550.c > @@ -38,11 +38,28 @@ > * can be specified in place of a numeric baud rate. Polled mode is specified > * by requesting irq 0. > */ > -static char __initdata

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

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

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

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

Re: [Xen-devel] [PATCH v2] x86/vlapic: Don't reset APIC ID when handling INIT signal

On Wed, Apr 19, 2017 at 08:17:14AM -0600, Jan Beulich wrote: On 19.04.17 at 08:40, wrote: >> @@ -1257,7 +1257,12 @@ void vlapic_reset(struct vlapic *vlapic) >> } >> vlapic_set_reg(vlapic, APIC_ICR, 0); >> vlapic_set_reg(vlapic, APIC_ICR2,0); >> -

Re: [Xen-devel] about fully UMIP support in Xen

On 19/04/17 15:27, Jan Beulich wrote: On 19.04.17 at 16:17, wrote: >> On 19/04/17 15:06, Jan Beulich wrote: >> On 19.04.17 at 15:49, wrote: If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace should be

  1   2   >