Re: [Xen-devel] [PATCH 2/6] x86/vpmu: Use vmx_{clear, set}_msr_intercept() rather than opencoding them

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 8:18 PM > > On 19/07/17 12:57, Andrew Cooper wrote: > > No functional change. > > > > Signed-off-by: Andrew Cooper > > I have just realise I can now drop msraddr_to_bitpos(), so

Re: [Xen-devel] [PATCH 1/6] x86/vmx: Improvements to vmx_{dis, en}able_intercept_for_msr()

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > * Shorten the names to vmx_{clear,set}_msr_intercept() > * Use an enumeration for MSR_TYPE rather than a plain integer > * Introduce VMX_MSR_RW, as most callers alter both the read and write >

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

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

[Xen-devel] (no subject)

Hi . I am ravi student from Indian I working on the xen arm development . I have plan to run the xen arm on fastmodel. But I am getting problem in the rootfilesystem creation and debootstrap for this link https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/RootFilesystem.

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

flight 112327 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112327/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 4 host-install(4)broken REGR. vs. 111765 build-arm64

Re: [Xen-devel] [PATCH] xen:arm earlyprintk configuration for Hikey 960 boards

On Wed, Jul 26, 2017 at 05:59:15PM +0100, Julien Grall wrote: > Hi Konrad, > > On 26/07/17 17:54, Konrad Rzeszutek Wilk wrote: > > Introduce an earlyprintk configuration of Hikey 960 boards. ..snip.. > > Would it be possible to update the wiki page on the hikey [1] with your > latest finding?

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

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 7/25/2017 5:21 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. > > > > Introduce a data structure named

Re: [Xen-devel] [PATCH v2 10/13] xen/pvcalls: implement poll command

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 07/25/2017 05:22 PM, Stefano Stabellini wrote: > > For active sockets, check the indexes and use the inflight_conn_req > > waitqueue to wait. > > > > For passive sockets, send PVCALLS_POLL to the backend. Use the > > inflight_accept_req waitqueue if

[Xen-devel] [PATCH v2 1/2] libxl: Implement the handler to handle unrecoverable AER errors.

Implement the callback function to handle unrecoverable AER errors, and also the public APIs that can be used to register/unregister the handler. When an AER error occurs, the handler will forcibly remove the erring PCIe device from the guest. Signed-off-by: Venu Busireddy

[Xen-devel] [PATCH v2 2/2] xl: Register the AER event handler to handle AER errors.

When a guest is created, register the AER event handler to handle the AER errors. When an AER error occurs, the handler will forcibly remove the erring PCIe device from the guest. Signed-off-by: Venu Busireddy --- tools/xl/xl_vmcontrol.c | 11 +++ 1 file

[Xen-devel] [PATCH v2 0/2] Containing AER unrecoverable errors

This patch set is part of a set of patches that together allow containment of unrecoverable AER errors from PCIe devices assigned to guests in passthrough mode. The containment is achieved by forcibly removing the erring PCIe device from the guest. The xen-pciback patch corresponding to this

Re: [Xen-devel] [PATCH v2 09/13] xen/pvcalls: implement recvmsg

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > >> + count++; > >> + else > >> + wait_event_interruptible(map->active.inflight_conn_req, > >> + pvcalls_front_read_todo(map)); > >> + } > > Should we be using

Re: [Xen-devel] [PATCH v2 05/13] xen/pvcalls: implement bind command

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 7/25/2017 5:22 PM, Stefano Stabellini wrote: > > Send PVCALLS_BIND to the backend. Introduce a new structure, part of > > struct sock_mapping, to store information specific to passive sockets. > > > > Introduce a status field to keep track of the

Re: [Xen-devel] [PATCH v2 07/13] xen/pvcalls: implement accept command

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 07/25/2017 05:22 PM, Stefano Stabellini wrote: > > Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make > > sure that only one accept command is executed at any given time by > > setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on

Re: [Xen-devel] [PATCH v2 10/13] xen/pvcalls: implement poll command

On 07/25/2017 05:22 PM, Stefano Stabellini wrote: > For active sockets, check the indexes and use the inflight_conn_req > waitqueue to wait. > > For passive sockets, send PVCALLS_POLL to the backend. Use the > inflight_accept_req waitqueue if an accept is outstanding. Otherwise use > the

Re: [Xen-devel] [PATCH v2 04/13] xen/pvcalls: implement connect command

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 7/25/2017 5:22 PM, Stefano Stabellini wrote: > > Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for > > the active socket. > > > > Introduce a data structure to keep track of sockets. Introduce a > > waitqueue to allow the

Re: [Xen-devel] [PATCH v2 03/13] xen/pvcalls: implement socket command and handle events

On Wed, 26 Jul 2017, Boris Ostrovsky wrote: > On 7/25/2017 5:22 PM, Stefano Stabellini wrote: > > Send a PVCALLS_SOCKET command to the backend, use the masked > > req_prod_pvt as req_id. This way, req_id is guaranteed to be between 0 > > and PVCALLS_NR_REQ_PER_RING. We already have a slot in the

[Xen-devel] [PATCH] libxl: do not start dom0 qemu for stubdomain when not needed

Use xen-blkback for 'vbd' disk types by default and do not setup vfb+vkb when no access method was configured. Then check if qemu is really needed. The only not configurable thing forcing qemu running in dom0 after this change are consoles used to save/restore. But even in that case, there is

Re: [Xen-devel] [PATCH v2 3/5] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong alignment.

On 26/07/2017 20:47, Konrad Rzeszutek Wilk wrote: > diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c > index 2247b925a0..7b36210ccd 100644 > --- a/xen/arch/arm/arm64/livepatch.c > +++ b/xen/arch/arm/arm64/livepatch.c > @@ -86,6 +86,12 @@ bool

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

flight 112324 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112324/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 4 host-install(4)broken REGR. vs. 112286 build-arm64-xsm

Re: [Xen-devel] [PATCH v2 09/13] xen/pvcalls: implement recvmsg

>> +while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) { >> +if (count < PVCALLS_FRONT_MAX_SPIN) >> +count++; >> +else >> +wait_event_interruptible(map->active.inflight_conn_req, >> +

[Xen-devel] [PATCH] libvchan: Fix cleanup when xc_gntshr_open failed

If xc_gntshr_open failed the only thing to cleanup is free allocated memory. So instead of calling libxenvchan_close (which assume valid calculated buffers being mmaped already) free memory and return. Signed-off-by: Marek Marczykowski-Górecki ---

Re: [Xen-devel] [PATCH v2 09/13] xen/pvcalls: implement recvmsg

On 07/25/2017 05:22 PM, Stefano Stabellini wrote: > Implement recvmsg by copying data from the "in" ring. If not enough data > is available and the recvmsg call is blocking, then wait on the > inflight_conn_req waitqueue. Take the active socket in_mutex so that > only one function can access the

Re: [Xen-devel] Next Xen ARM community call - Wednesday 2nd August 2017

Hi, this time works for me too. I'd like to have a slot to introduce and discuss the work that Xilinx and Aggios are doing on Power management for Xen/Arm. Cheers, Edgar Sent from my phone On Jul 26, 2017 6:59 PM, "Stefano Stabellini" wrote: > On Wed, 26 Jul 2017,

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

> On Jul 26, 2017, at 2:43 PM, Juergen Gross wrote: > >> On 26/07/17 19:57, Andy Lutomirski wrote: >> >> On Jul 26, 2017, at 11:50 AM, Juergen Gross wrote: > On 26/07/17 15:48, Andy Lutomirski wrote: > On Mon, Jul 24, 2017 at 7:28 AM,

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

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

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

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

[Xen-devel] [PATCH v2 3/5] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong alignment.

This issue was observed on ARM32 with a cross compiler for the livepatches. Mainly the livepatches .data section size was not padded to the section alignment: ARM32 native: Contents of section .rodata: 68695f66 756e6300 63686563 6b5f666e hi_func.check_fn 0010 6300 78656e5f 65787472

[Xen-devel] [PATCH v2 1/5] livepatch: Tighten alignment checks.

From: Konrad Rzeszutek Wilk The ELF specification mentions nothing about the sh_size being modulo the sh_addralign. Only that sh_addr MUST be aligned on sh_addralign if sh_addralign is not zero or one. We on loading did not take this in-to account so this patch adds a

[Xen-devel] [PATCH v2 5/5] livepatch: Declare live patching as a supported feature

From: Ross Lagerwall See docs/features/livepatch.pandoc for the details. Signed-off-by: Ross Lagerwall Signed-off-by: Konrad Rzeszutek Wilk -- v2: - Moved it into a feature document. - Clarified a few bits and pieces

[Xen-devel] [PATCH v2] Livepatch fixes for v4.10 (v2).

Since v1 (https://lists.xen.org/archives/html/xen-devel/2017-07/msg01127.html) - Redid the patches per review comments, - Included fixes for the errant sections causing the crash, - Rolled in patch from Ross in this patchset, Hey, I've been working towards making the livepatch-build-tools to

[Xen-devel] [PATCH v2 2/5] livepatch: Include sizes when an mismatch occurs

From: Konrad Rzeszutek Wilk If the .bug.frames.X or .livepatch.funcs sizes are different than what the hypervisor expects - we fail the payload. To help in diagnosing this include the expected and the payload sizes. Also make it more natural by having "Multiples" in the

[Xen-devel] [PATCH v2 4/5] alternative/x86/arm32: Align altinstructions (and altinstr_replacement) sections.

This is very similar to 137c59b9ff3f7a214f03b52d9c00a0a02374af1f "bug/x86/arm: Align bug_frames sections." On ARM and on x86 the C and assembler macros don't include any alignment information - hence they end up being the default byte granularity. On ARM32 it is paramount that the alignment is

Re: [Xen-devel] [PATCH v2 1/3] x86: nuke PV superpage option and code

On Wed, Jul 26, 2017 at 05:19:02PM +0100, Andrew Cooper wrote: > On 26/07/17 08:44, Wei Liu wrote: > > Delete the user visible option and code for PV superpage support. The > > mm code is modified as if the option is set to false (the default > > value). > > > > Return the address space occupied

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On 26/07/17 19:57, Andy Lutomirski wrote: > > >> On Jul 26, 2017, at 11:50 AM, Juergen Gross wrote: >> >>> On 26/07/17 15:48, Andy Lutomirski wrote: On Mon, Jul 24, 2017 at 7:28 AM, Juergen Gross wrote: When running as Xen pv-guest the exception

Re: [Xen-devel] [RFC PATCH v3 22/24] ARM: NUMA: Initialize ACPI NUMA

Hi Vijay, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Call ACPI NUMA initialization under CONFIG_ACPI_NUMA. Signed-off-by: Vijaya Kumar --- xen/arch/arm/numa/acpi_numa.c | 27 ++-

Re: [Xen-devel] [RFC PATCH v3 21/24] ARM: NUMA: ACPI: Extract proximity from SRAT table

Hi, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Register SRAT entry handler for type ACPI_SRAT_TYPE_GICC_AFFINITY to parse SRAT table and extract proximity for all CPU IDs. Signed-off-by: Vijaya Kumar Please split

Re: [Xen-devel] [RFC PATCH v3 19/24] ARM: NUMA: Extract MPIDR from MADT table

Hi Vijay, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Parse MADT table and extract MPIDR for all CPU IDs in MADT ACPI_MADT_TYPE_GENERIC_INTERRUPT entries and store in cpuid_to_hwid_map[] This mapping is used by SRAT table parsing to extract

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

> On Jul 26, 2017, at 11:50 AM, Juergen Gross wrote: > >> On 26/07/17 15:48, Andy Lutomirski wrote: >>> On Mon, Jul 24, 2017 at 7:28 AM, Juergen Gross wrote: >>> When running as Xen pv-guest the exception frame on the stack contains >>> %r11 and %rcx

Re: [Xen-devel] [PATCH v2 07/13] xen/pvcalls: implement accept command

On 07/25/2017 05:22 PM, Stefano Stabellini wrote: > Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make > sure that only one accept command is executed at any given time by > setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the > inflight_accept_req waitqueue. > >

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

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

Re: [Xen-devel] [RFC PATCH v3 17/24] ARM: NUMA: DT: Do not expose numa info to DOM0

Hi, On 18/07/17 12:41, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Delete numa-node-id and distance map from DOM0 DT so that NUMA information is not exposed to DOM0. This helps particularly to boot Node 1 devices as if booting on Node0. However this approach

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

On Wed, 26 Jul 2017, Julien Grall wrote: > Hi Stefano, > > On 25/07/17 20:06, Stefano Stabellini wrote: > > On Tue, 25 Jul 2017, Julien Grall wrote: > > > On 25/07/17 19:48, Stefano Stabellini wrote: > > > > On Tue, 25 Jul 2017, Julien Grall wrote: > > > > > On 25/07/17 07:47, Vijay Kilari wrote:

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

Hi Stefano, On 25/07/17 20:06, Stefano Stabellini wrote: On Tue, 25 Jul 2017, Julien Grall wrote: On 25/07/17 19:48, Stefano Stabellini wrote: On Tue, 25 Jul 2017, Julien Grall wrote: On 25/07/17 07:47, Vijay Kilari wrote: void numa_failed(void) { numa_off = true;

Re: [Xen-devel] [PATCH] xen:arm earlyprintk configuration for Hikey 960 boards

On Wed, 26 Jul 2017, Julien Grall wrote: > Hi Konrad, > > On 26/07/17 17:54, Konrad Rzeszutek Wilk wrote: > > Introduce an earlyprintk configuration of Hikey 960 boards. > > > > Tested with: > > https://github.com/96boards-hikey/edk2.git #testing/hikey960_v2.5 > >

[Xen-devel] [PATCH v2] scripts/get_maintainers.pl: Don't blindly drop "THE REST" maintainers

"THE REST" maintainers should always be CCed for any modification that don't fall under the responsability of a specific component maintainer. However, the script get_maintainers.pl will remove "THE REST" maintainers as soon as one maintainer of a specific component will be present. Fix the

Re: [Xen-devel] [PATCH] scripts/get_maintainers.pl: Don't blindly drop "THE REST" maintainers

Hi Ian, On 26/07/17 15:27, Ian Jackson wrote: Julien Grall writes ("[Xen-devel] [PATCH] scripts/get_maintainers.pl: Don't blindly drop "THE REST" maintainers"): "THE REST" maintainers should always be CCed for any modification that don't fall under the responsability of a specific component

Re: [Xen-devel] Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

On 26/07/17 16:04, Andrii Anisov wrote: Dear All, Hi, I would like to revive this thread within the R-Car Gen3 support nits cleanup work. On 01.12.16 02:12, Stefano Stabellini wrote: Before answering about possible implementation in Xen, I would like to understand what are the

Re: [Xen-devel] [PATCH] xen:arm earlyprintk configuration for Hikey 960 boards

Hi Konrad, On 26/07/17 17:54, Konrad Rzeszutek Wilk wrote: Introduce an earlyprintk configuration of Hikey 960 boards. Tested with: https://github.com/96boards-hikey/edk2.git #testing/hikey960_v2.5 https://github.com/96boards-hikey/OpenPlatformPkg.git #testing/hikey960_v1.3.4

Re: [Xen-devel] Next Xen ARM community call - Wednesday 2nd August 2017

On Wed, 26 Jul 2017, Julien Grall wrote: > Hi all, > > The next Xen ARM community call will be Wednesday 2nd August 2017 5pm BST. > > Do you have any specific topic you would like to discuss? These date and time work for me. I don't have any specific topics to discuss. > Call+44

[Xen-devel] [PATCH] xen:arm earlyprintk configuration for Hikey 960 boards

Introduce an earlyprintk configuration of Hikey 960 boards. Tested with: https://github.com/96boards-hikey/edk2.git #testing/hikey960_v2.5 https://github.com/96boards-hikey/OpenPlatformPkg.git #testing/hikey960_v1.3.4 https://git.savannah.gnu.org/git/grub.git #master

Re: [Xen-devel] Xen checkpatch infrastructure design

> We did not plan any changes into the clang-format yet. We have to check with > Artem our next steps. I don't think this is a huge task. I think it is also something that is important enough for the Advisory Board to make funds available – assuming this can't be done otherwise (but I can't

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

Hi Chris, On 07/07/17 19:08, Chris Patterson wrote: On Fri, Jul 7, 2017 at 12:25 PM, Julien Grall wrote: Hi Chris, On 06/07/17 23:00, Chris Patterson wrote: The purpose of tegra_interrupt_compat is to maintain a tegra-specific whitelist of interrupt controllers we

Re: [Xen-devel] [PATCH v2 1/3] x86: nuke PV superpage option and code

On Wed, Jul 26, 2017 at 05:19:02PM +0100, Andrew Cooper wrote: > On 26/07/17 08:44, Wei Liu wrote: > > Delete the user visible option and code for PV superpage support. The > > mm code is modified as if the option is set to false (the default > > value). > > > > Return the address space occupied

Re: [Xen-devel] [PATCH] AMD IOMMU: drop amd_iommu_setup_hwdom_device()

>>> Roger Pau Monné 07/17/17 1:31 PM >>> >On Fri, Jul 14, 2017 at 08:04:16AM -0600, Jan Beulich wrote: >> By moving its bridge special casing to amd_iommu_add_device(), we can >> pass the latter to setup_hwdom_pci_devices() and at once consistently >> handle bridges

Re: [Xen-devel] [PATCH v2 1/3] x86: nuke PV superpage option and code

On 26/07/17 08:44, Wei Liu wrote: > Delete the user visible option and code for PV superpage support. The > mm code is modified as if the option is set to false (the default > value). > > Return the address space occupied by spage_info back to the reserved > address space. > > Signed-off-by: Wei

Re: [Xen-devel] [PATCH 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing

Hi Chris, Sorry for the late reply. On 24/07/17 20:38, Chris Patterson wrote: On Fri, Jul 7, 2017 at 2:53 PM, Chris Patterson wrote: On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall wrote: Hi Chris, On 07/07/17 00:12, Chris Patterson wrote: So why

Re: [Xen-devel] Xen checkpatch infrastructure design

Hi Lars, > I was wondering how you deal with the gaps. I suppose these gaps could > possibly be covered in clang-format-diff.py > Of course this info may be out-of-date I assumed that everything is fine with clang-format and started with python script. Now I have checked both

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

flight 112314 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112314/ 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

[Xen-devel] Next Xen ARM community call - Wednesday 2nd August 2017

Hi all, The next Xen ARM community call will be Wednesday 2nd August 2017 5pm BST. Do you have any specific topic you would like to discuss? Call+44 1223 406065 (Local dial in) and enter the access code below followed by # key. Participant code: 4915191 Mobile Auto Dial:

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On 26/07/17 15:48, Andy Lutomirski wrote: > On Mon, Jul 24, 2017 at 7:28 AM, Juergen Gross wrote: >> When running as Xen pv-guest the exception frame on the stack contains >> %r11 and %rcx additional to the other data pushed by the processor. >> >> Instead of having a paravirt op

Re: [Xen-devel] [OSSTEST PATCH v13 21/24] Create a flight to test OpenStack with xen-unstable and libvirt

Anthony PERARD writes ("Re: [OSSTEST PATCH v13 21/24] Create a flight to test OpenStack with xen-unstable and libvirt"): > On Tue, Jul 25, 2017 at 07:09:06PM +0100, Ian Jackson wrote: > > Anthony PERARD writes ("[OSSTEST PATCH v13 21/24] Create a flight to test > > OpenStack with xen-unstable

Re: [Xen-devel] [OSSTEST PATCH v13 24/24] openstack tests: Don't run them on arm*

Anthony PERARD writes ("Re: [OSSTEST PATCH v13 24/24] openstack tests: Don't run them on arm*"): > On Tue, Jul 25, 2017 at 07:18:21PM +0100, Ian Jackson wrote: > > Anthony PERARD writes ("[OSSTEST PATCH v13 24/24] openstack tests: Don't > > run them on arm*"): > > > Signed-off-by: Anthony PERARD

Re: [Xen-devel] [OSSTEST PATCH v13 19/24] TestSupport: Implement target_subunit_cmd a subunit stream parser into substeps

Anthony PERARD writes ("Re: [OSSTEST PATCH v13 19/24] TestSupport: Implement target_subunit_cmd a subunit stream parser into substeps"): > I think I start by looking at what kind of characters could be part of > type and sub-type, and just start writing a more complicated regex. > > So is the

Re: [Xen-devel] [PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk

Hello Julien, On 26.07.17 18:33, Julien Grall wrote: On 26/07/17 16:25, Andrii Anisov wrote: + Stefano as a maintainer. Dear all, Any objections on this patch? I would have appreciated to be CC as well... Somewhy I though you are in the thread of this patch as well. Sorry for my miss.

Re: [Xen-devel] Xen checkpatch infrastructure design

Hello, Juergen > How does this work for a patch which is perfectly fine, while not > touched parts of the patched file are not? The tool should only > look at the added lines, not at those left unmodified. The tool looks at touched lines only since it works with unified diff and parse it. As

Re: [Xen-devel] [PATCH 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards

Hi, On 26/07/17 16:25, Andrii Anisov wrote: + Stefano as a maintainer. Dear all, Any objections on this patch? Same as patch #1 here. On 05.07.17 19:29, Andrii Anisov wrote: From: Andrii Anisov Introduce an earlyprintk configuration for R-Car Gen3 SoC based

Re: [Xen-devel] [PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk

On 26/07/17 16:25, Andrii Anisov wrote: + Stefano as a maintainer. Dear all, Any objections on this patch? I would have appreciated to be CC as well... > On 05.07.17 19:29, Andrii Anisov wrote: From: Iurii Konovalenko Add support for a SCIF

Re: [Xen-devel] Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

@Committers, @Julien, > On 26 Jul 2017, at 13:53, Lars Kurth wrote: >> Improving the Process >> = >> >> JIRA >> >> Open source projects do NOT need licenses for JIRA: these was raised by >> OpenXT folks, who use JIRA >> >> ACTION: Lars to

Re: [Xen-devel] [PATCH 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards

+ Stefano as a maintainer. Dear all, Any objections on this patch? On 05.07.17 19:29, Andrii Anisov wrote: From: Andrii Anisov Introduce an earlyprintk configuration for R-Car Gen3 SoC based development boards, like: - Salvator-X

Re: [Xen-devel] [PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk

+ Stefano as a maintainer. Dear all, Any objections on this patch? On 05.07.17 19:29, Andrii Anisov wrote: From: Iurii Konovalenko Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs. Signed-off-by: Iurii Konovalenko

Re: [Xen-devel] [OSSTEST PATCH v13 18/24] TestSupport: Introduce target_cmd_stashed

On Tue, Jul 25, 2017 at 07:26:07PM +0100, Ian Jackson wrote: > Anthony PERARD writes ("[OSSTEST PATCH v13 18/24] TestSupport: Introduce > target_cmd_stashed"): > > This works like target_cmd, but takes a ref to a filename as argument > > and stash the output of the command then return a path to

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

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

Re: [Xen-devel] [OSSTEST PATCH v13 24/24] openstack tests: Don't run them on arm*

On Tue, Jul 25, 2017 at 07:18:21PM +0100, Ian Jackson wrote: > Anthony PERARD writes ("[OSSTEST PATCH v13 24/24] openstack tests: Don't run > them on arm*"): > > Signed-off-by: Anthony PERARD > > Acked-by: Ian Jackson > > You should

Re: [Xen-devel] [OSSTEST PATCH v13 21/24] Create a flight to test OpenStack with xen-unstable and libvirt

On Tue, Jul 25, 2017 at 07:09:06PM +0100, Ian Jackson wrote: > Anthony PERARD writes ("[OSSTEST PATCH v13 21/24] Create a flight to test > OpenStack with xen-unstable and libvirt"): > > This patch creates a flight "openstack*", with those jobs: > > Do you mean it creates a "branch" ? But I

Re: [Xen-devel] Xen 4.10 Development Update

Hi, Julien On Thu, Jul 20, 2017 at 8:27 PM, Julien Grall wrote: > On 20/07/17 17:57, Manish Jaggi wrote: >> >> Hi Julien, > > > Hello Manish, > > I am not sure why piggyback on Daniel Kiper as it is not related to your > work... > > >>> On Mon, Jul 17, 2017 at 02:26:22PM

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On 26/07/17 15:48, Andy Lutomirski wrote: > On Mon, Jul 24, 2017 at 7:28 AM, Juergen Gross wrote: >> When running as Xen pv-guest the exception frame on the stack contains >> %r11 and %rcx additional to the other data pushed by the processor. >> >> Instead of having a paravirt op

[Xen-devel] [PATCH 0/2 v3] xenfb: rework xen vkbd backend

These patches are intended to allow PV frontends, like the Windows frontend to use the backend provided by Qemu. The Windows frontend(1) requires absolute mouse coordinates in a fixed range, which is not possible under HVM guests, where the vfb and Qemu console is not guaranteed to be available or

[Xen-devel] [PATCH 2/2 v3] xenfb: Add [feature|request]-raw-pointer

Writes "feature-raw-pointer" during init to indicate the backend can pass raw unscaled values for absolute axes to the frontend. Frontends set "request-raw-pointer" to indicate the backend should not attempt to scale absolute values to console size. "request-raw-pointer" is only valid if

[Xen-devel] [PATCH 1/2 v3] xenfb: Use Input Handlers directly

Avoid the unneccessary calls through the input-legacy.c file by using the qemu_input_handler_*() calls directly. This did require reworking the event and sync handlers and a direct mapping from QEMU's qcodes to linux KEY_* identifiers required by the ring protocol. Removes the scancode2linux

[Xen-devel] [RFC PATCH v1 0/7] IPMMU-VMSA support on ARM

From: Oleksandr Tyshchenko Hi, all. The purpose of this patch series is to add IPMMU-VMSA support to Xen on ARM. It is VMSA-compatible IOMMU that integrated in the newest Renesas R-Car Gen3 SoCs (ARM). And this IOMMU can't share the page table with the CPU since

[Xen-devel] [RFC PATCH v1 3/7] iommu/arm: ipmmu-vmsa: Add io-pgtables support

From: Oleksandr Tyshchenko The Linux IPMMU driver which is being ported to Xen relies on this Linux framework. Moreover, as the IPMMU is a non-shared IOMMU we must have a way of manipulating it's page table. So, copy it as is for now to simplify things, but we

[Xen-devel] [RFC PATCH v1 7/7] iommu/arm: ipmmu-vmsa: Enable VMSAv8-64 mode if IPMMU HW supports it

From: Oleksandr Tyshchenko The patch was ported from RFC patch for Linux and slightly modified in order to handle IOVA space above 32-bit. iommu/ipmmu-vmsa: Initial R-Car Gen3 VA64 mode support https://patchwork.kernel.org/patch/9532335/ Modifications to the

[Xen-devel] [RFC PATCH v1 6/7] iommu/arm: ipmmu-vmsa: Deallocate page table asynchronously

From: Oleksandr Tyshchenko This is the PoC how to optimize page table deallocation sequence by splitting it into separate chunks. Use iommu_pt_cleanup_list to queue pages that need to be handled and freed next time. Use free_page_table platform callback to dequeue

[Xen-devel] [RFC PATCH v1 2/7] iommu/arm: ipmmu-vmsa: Add Xen changes for main driver

From: Oleksandr Tyshchenko Modify the Linux IPMMU driver to be functional inside Xen. All devices within a single Xen domain must use the same IOMMU context no matter what IOMMU domains they are attached to. This is the main difference between drivers in Linux and

[Xen-devel] [RFC PATCH v1 1/7] iommu/arm: ipmmu-vmsa: Add IPMMU-VMSA support

From: Oleksandr Tyshchenko It is VMSA-compatible IOMMU that integrated in the newest Renesas SoCs (ARM). Copy Linux IPMMU driver as is for now. Next patches will show what is going on. Linux driver was taken here:

[Xen-devel] [RFC PATCH v1 5/7] iommu/arm: Build IPMMU-VMSA related stuff

From: Oleksandr Tyshchenko Signed-off-by: Oleksandr Tyshchenko CC: Julien Grall CC: Stefano Stabellini --- xen/drivers/passthrough/arm/Makefile | 3 +++ 1 file changed, 3 insertions(+)

[Xen-devel] [RFC PATCH v1 4/7] iommu/arm: ipmmu-vmsa: Add Xen changes for io-pgtables

From: Oleksandr Tyshchenko Modify the Linux framework to be functional inside Xen. It's mostly about differences between memory manipulations in Xen and Linux. Also wrap following code in #if 0: - All DMA related stuff - Stage-2 related things - Self test

[Xen-devel] Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

Dear All, I would like to revive this thread within the R-Car Gen3 support nits cleanup work. On 01.12.16 02:12, Stefano Stabellini wrote: Before answering about possible implementation in Xen, I would like to understand what are the constraints on these reserved memory regions. I

Re: [Xen-devel] [OSSTEST PATCH v13 19/24] TestSupport: Implement target_subunit_cmd a subunit stream parser into substeps

On Tue, Jul 25, 2017 at 07:00:47PM +0100, Ian Jackson wrote: > Anthony PERARD writes ("[OSSTEST PATCH v13 19/24] TestSupport: Implement > target_subunit_cmd a subunit stream parser into substeps"): > > target_subunit_cmd can be used like target_cmd, but the command would > > needs to output a

Re: [Xen-devel] [PATCH v2 05/13] xen/pvcalls: implement bind command

On 7/25/2017 5:22 PM, Stefano Stabellini wrote: Send PVCALLS_BIND to the backend. Introduce a new structure, part of struct sock_mapping, to store information specific to passive sockets. Introduce a status field to keep track of the status of the passive socket. Introduce a waitqueue for

Re: [Xen-devel] A document for Xen release management, v2

On Wed, Jul 26, 2017 at 03:31:29PM +0100, Lars Kurth wrote: > Hi all, > > > On 25 Jul 2017, at 14:25, Wei Liu wrote: > > > > Hi all > > > > This is v2 of this document. > > > > Lars, please insert your section as you see fit. > > Done + some other minor mods Merged into

Re: [Xen-devel] [PATCH 5/5] tools: tracing: handle null scheduler's events

On Thu, Jun 29, 2017 at 1:56 PM, Dario Faggioli wrote: > In both xentrace and xenalyze. > > Signed-off-by: Dario Faggioli Acked-by: George Dunlap ___ Xen-devel mailing

Re: [Xen-devel] [PATCH v2 04/13] xen/pvcalls: implement connect command

On 7/25/2017 5:22 PM, Stefano Stabellini wrote: Send PVCALLS_CONNECT to the backend. Allocate a new ring and evtchn for the active socket. Introduce a data structure to keep track of sockets. Introduce a waitqueue to allow the frontend to wait on data coming from the backend on the active

Re: [Xen-devel] [PATCH 4/5] xen: sched_null: add some tracing

On Thu, Jun 29, 2017 at 1:56 PM, Dario Faggioli wrote: > In line with what is there in all the other schedulers. > > Signed-off-by: Dario Faggioli Reviewed-by: George Dunlap

[Xen-devel] [PATCH v3 0/3] docs: convert manpages to pod

To remove the buildtime dependency to pandoc/ghc some manpages are converted from markdown to pod format. This will provide more manpages which are referenced in xl(1) and xl.cfg(5). This series does not cover xen-vbd-interface.7 because converting the lists used in this manpage was not straight

[Xen-devel] [PATCH v3 1/3] docs: add pod variant of xen-pv-channel.7

Convert source for xen-pv-channel.7 from markdown to pod. This removes the buildtime requirement for pandoc, and subsequently the need for ghc, in the chain for BuildRequires of xen.rpm. Signed-off-by: Olaf Hering --- docs/man/xen-pv-channel.markdown.7 | 106

[Xen-devel] [PATCH v3 2/3] docs: add pod variant of xl-network-configuration.5

Convert source for xl-network-configuration.5 from markdown to pod. This removes the buildtime requirement for pandoc, and subsequently the need for ghc, in the chain for BuildRequires of xen.rpm. Signed-off-by: Olaf Hering --- ...n.markdown.5 => xl-network-configuration.pod.5}

[Xen-devel] [PATCH v3 3/3] docs: add pod variant of xl-numa-placement

Convert source for xl-numa-placement.7 from markdown to pod. This removes the buildtime requirement for pandoc, and subsequently the need for ghc, in the chain for BuildRequires of xen.rpm. Signed-off-by: Olaf Hering --- ...lacement.markdown.7 => xl-numa-placement.pod.7} | 166

Re: [Xen-devel] [PATCH v1] xen: get rid of paravirt op adjust_exception_frame

On 26/07/17 15:09, Andy Lutomirski wrote: > On Wed, Jul 26, 2017 at 7:01 AM, Andrew Cooper > wrote: >> On 26/07/17 14:48, Andy Lutomirski wrote: /* Runs on exception stack */ -ENTRY(nmi) - /* -* Fix up the exception frame if we're on

  1   2   >