Re: [Xen-devel] [PATCH v4] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

Hi Julien, On Mon, Apr 3, 2017 at 3:31 PM, Julien Grall wrote: > Hi Vijay, > > On 28/03/17 13:35, vijay.kil...@gmail.com wrote: >> >> From: Vijaya Kumar K >> >> On ARM64, virt_to_mfn uses the hardware for address >> translation. So if the virtual

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

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

[Xen-devel] [xen-4.6-testing baseline-only test] 71144: tolerable trouble: broken/fail/pass

This run is configured for baseline tests only. flight 71144 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71144/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 19 capture-logs(19)

[Xen-devel] Xen Code Review Dashboard

Team, I am interested in the project and would like to begin contributing. It would be good to speak with a team lead about the project at a high level, and to identify areas where I can provide quick wins. In addition to CSS/HTML, my languages are JS, PHP, and SQL. Thank you for your

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

flight 107164 linux-arm-xen real [real] http://logs.test-lab.xenproject.org/osstest/logs/107164/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 62674

Re: [Xen-devel] Can't ./configure latest git

In addition, I had to grep -r -l '$(PYTHON)' * | xargs sed -i 's!$(PYTHON)!/usr/bin/python2!g' because I couldn't figure out where $(PYTHON) was set. At first I thought it was tools/get-fields.sh but setting it there didn't fix it. On Mon, Apr 3, 2017 at 7:25 PM Duncan X. Simpson

Re: [Xen-devel] Can't ./configure latest git

Worked around with the following: ~git/xen   master ± git diff diff --git a/tools/configure b/tools/configure index 7a57e6562d..874498ad80 100755 --- a/tools/configure +++ b/tools/configure @@ -6859,7 +6859,7 @@ if echo "$PYTHON" | grep -q "^/"; then : PYTHON=`basename $PYTHONPATH`

[Xen-devel] Can't ./configure latest git

I just cloned Xen from git, but it won't configure. I have both versions of Python installed, but it tries to use 3 to run 2 code: checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes File "", line 1 import distutils.sysconfig;

Re: [Xen-devel] Can't read bios file

I apologize, I should probably include this information: OS: Arch Linux xl info: host : k7dxs-laptop-r500 release: 4.10.6-1-ARCH version: #1 SMP PREEMPT Mon Mar 27 08:28:22 CEST 2017 machine: x86_64 nr_cpus: 2

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

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

[Xen-devel] Can't read bios file

I'm trying to set up an HVM CentOS guest, and I've run into a problem. I originally tried posting it on Stack Exchange ( https://superuser.com/questions/1193771/failed-to-read-bios-file-no-such-file-or-directory), but it is not documented anywhere on the Internet that Google can see and I have

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

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

[Xen-devel] [PATCH v6 1/2] arm: remove irq from inflight, then change physical affinity

This patch fixes a potential race that could happen when gic_update_one_lr and vgic_vcpu_inject_irq run simultaneously. When GIC_IRQ_GUEST_MIGRATING is set, we must make sure that the irq has been removed from inflight before changing physical affinity, to avoid concurrent accesses to

[Xen-devel] [PATCH v6 2/2] vgic: refuse irq migration when one is already in progress

When an irq migration is already in progress, but not yet completed (GIC_IRQ_GUEST_MIGRATING is set), refuse any other irq migration requests for the same irq. This patch implements this approach by returning success or failure from vgic_migrate_irq, and avoiding irq target changes on failure. It

[Xen-devel] [PATCH v6 0/2] xen/arm: remove race conditions in irq migration

Hi all, this patch series removes three race conditions affecting the current code base. The first race condition is between gic_update_one_lr and vgic_vcpu_inject_irq: as soon as gic_update_one_lr calls irq_set_affinity a new interrupt could be injected in the new pcpu, eventually

Re: [Xen-devel] [Outreachy] Interested to Work on Xen Code Review Dashboard

On Tue, 2017-04-04 at 05:07 +0530, Pooja wrote: > Hello mentors, > > I'd like to work on the new Xen Code Dashboard extensions project as > part of applying to Outreachy Rd 14, 2017. > > I've been working in front end development since 2013, and am quite > comfortable in JavaScript, jQuery,

[Xen-devel] [Outreachy] Interested to Work on Xen Code Review Dashboard

Hello mentors, I'd like to work on the new Xen Code Dashboard extensions project as part of applying to Outreachy Rd 14, 2017. I've been working in front end development since 2013, and am quite comfortable in JavaScript, jQuery, JSON, CSS frameworks, SQL besides HTML5/CSS3. I'd really

Re: [Xen-devel] [Outreachy] Interested to Work on Xen Code Review Dashboard

Hello mentors, I'd like to work on the new Xen Code Dashboard extensions project as part of applying to Outreachy Rd 14, 2017. I've been working in front end development since 2013, and am quite comfortable in JavaScript, jQuery, JSON, CSS frameworks, SQL besides HTML5/CSS3. I'd really

[Xen-devel] [Outreachy] Interested to Work on Xen Code Review Dashboard

Hello mentors, I'd like to work on the new Xen Code Dashboard extensions project as part of applying to Outreachy Rd 14, 2017. I've been working in front end development since 2013, and am quite comfortable in JavaScript, jQuery, JSON, CSS frameworks, SQL besides HTML5/CSS3. I'd really

Re: [Xen-devel] [PATCH v4 07/27] ARM: GICv3 ITS: introduce host LPI array

Hi Andre, On 04/03/2017 09:28 PM, Andre Przywara wrote: /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */ void gicv3_its_dt_init(const struct dt_device_node *node) { diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c index 8b3660a..d3ee141 100644

Re: [Xen-devel] [PATCH v4 06/27] ARM: GICv3 ITS: introduce ITS command handling

Hi Andre, On 04/03/2017 09:28 PM, Andre Przywara wrote: +#define BUFPTR_MASK GENMASK_ULL(19, 5) +static int its_send_command(struct host_its *hw_its, const void *its_cmd) +{ +/* Some small grace period in case the command queue is congested. */ This comment is a nice

Re: [Xen-devel] [PATCH v5] altp2m: Allow specifying external-only use-case

On Mon, Apr 3, 2017 at 3:24 PM, Tamas K Lengyel wrote: > On Tue, Mar 28, 2017 at 12:59 PM, Daniel De Graaf > wrote: >> On 03/22/2017 02:07 PM, Tamas K Lengyel wrote: >>> >>> Currently setting altp2mhvm=1 in the domain configuration allows

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

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

Re: [Xen-devel] [PATCH v4 05/27] ARM: GICv3 ITS: map ITS command buffer

Hi Andre, On 04/03/2017 09:28 PM, Andre Przywara wrote: Instead of directly manipulating the tables in memory, an ITS driver sends commands via a ring buffer in normal system memory to the ITS h/w to create or alter the LPI mappings. Allocate memory for that buffer and tell the ITS about it to

Re: [Xen-devel] [PATCH v4 03/27] ARM: GICv3: allocate LPI pending and property table

Hi Andre, Yeah... another round repeating the same things. On 04/03/2017 09:28 PM, Andre Przywara wrote: diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c new file mode 100644 index 000..a003a72 --- /dev/null +++ b/xen/arch/arm/gic-v3-lpi.c [...] +#include +#include

Re: [Xen-devel] [GSoc] GSoc Introduction : Xen on ARM: create multiple guests from device tree

Hi, On 04/03/2017 10:19 PM, Stefano Stabellini wrote: On Mon, 3 Apr 2017, Methuku Karthik wrote: What we would like is to be able to extract the .config from a xen binary manually, for example using the "strings" command. Let's supposed that a user is running Xen and finds a bug. We asked her

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

flight 107152 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107152/ 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. 107055 Regressions

Re: [Xen-devel] [PATCH v5 3/3] xen/arm: vgic_migrate_irq: do not race against GIC_IRQ_GUEST_MIGRATING

On Mon, 3 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 31/03/17 21:24, Stefano Stabellini wrote: > > On Fri, 31 Mar 2017, Julien Grall wrote: > > > On 30/03/17 00:47, Stefano Stabellini wrote: > > > > On Fri, 3 Mar 2017, Julien Grall wrote: > > > What you described is not a data corruption

Re: [Xen-devel] [PATCH v5] altp2m: Allow specifying external-only use-case

On Tue, Mar 28, 2017 at 12:59 PM, Daniel De Graaf wrote: > On 03/22/2017 02:07 PM, Tamas K Lengyel wrote: >> >> Currently setting altp2mhvm=1 in the domain configuration allows access to >> the >> altp2m interface for both in-guest and external privileged tools. This >>

Re: [Xen-devel] [GSoc] GSoc Introduction : Xen on ARM: create multiple guests from device tree

On Mon, 3 Apr 2017, Methuku Karthik wrote: > Hi Stefano, > > I have asked questions in inline. Clarification below questions would really > help me in contribution. Please look into the questions. I am highlighting > them in this mail. Hi Methuku, please do not use HTML in emails. >  For

Re: [Xen-devel] [PATCH v4 02/27] ARM: GICv3 ITS: initialize host ITS

Hi Andre, On 04/03/2017 09:28 PM, Andre Przywara wrote: Map the registers frame for each host ITS and populate the host ITS structure with some parameters describing the size of certain properties like the number of bits for device IDs. Introduce a command line parameter to limit the number of

Re: [Xen-devel] [PATCH v3 03/26] ARM: GICv3 ITS: allocate device and collection table

On 04/03/2017 08:39 PM, Andre Przywara wrote: Hi, On 03/04/17 18:22, Julien Grall wrote: Hi Andre, On 03/04/17 16:38, Julien Grall wrote: On 31/03/17 19:05, Andre Przywara wrote: Each ITS maps a pair of a DeviceID (for instance derived from a PCI b/d/f triplet) and an EventID (the MSI

Re: [Xen-devel] [PATCH v2] setup vwfi correctly on cpu0

On Mon, 3 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 03/31/2017 11:37 PM, Stefano Stabellini wrote: > > parse_vwfi runs after init_traps on cpu0, potentially resulting in the > > wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their > > case init_traps will write the

Re: [Xen-devel] [PATCH v2 06/27] ARM: GICv3 ITS: introduce device mapping

On 04/03/2017 09:08 PM, Andre Przywara wrote: Hi, Hi Andre, On 22/03/17 17:29, Julien Grall wrote: +int gicv3_its_map_guest_device(struct domain *d, + paddr_t host_doorbell, uint32_t host_devid, + paddr_t guest_doorbell, uint32_t

Re: [Xen-devel] [PATCH v6 0/7] Xen transport for 9pfs frontend driver

I'll ask the other Xen maintainers to queue this up on the Xen tree for the appropriate merge window. If you are not OK with that, please shout. On Thu, 23 Mar 2017, Stefano Stabellini wrote: > 9pfs maintainers, > > The patch series is fully acked, except for the header import from Xen >

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

On Mon, 3 Apr 2017, Oleksandr Tyshchenko wrote: > On Mon, Apr 3, 2017 at 9:06 PM, Julien Grall wrote: > > Hi Andrew, > > > > > > On 03/04/17 18:16, Andrew Cooper wrote: > >> > >> On 03/04/17 18:02, Julien Grall wrote: > >>> > >>> Hi Andrew, > >>> > >>> On 03/04/17 17:42,

[Xen-devel] [PATCH v4 01/27] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

Parse the DT GIC subnodes to find every ITS MSI controller the hardware offers. Store that information in a list to both propagate all of them later to Dom0, but also to be able to iterate over all ITSes. This introduces an ITS Kconfig option. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v4 06/27] ARM: GICv3 ITS: introduce ITS command handling

To be able to easily send commands to the ITS, create the respective wrapper functions, which take care of the ring buffer. The first two commands we implement provide methods to map a collection to a redistributor (aka host core) and to flush the command queue (SYNC). Start using these commands

[Xen-devel] [PATCH v4 25/27] ARM: vITS: create and initialize virtual ITSes for Dom0

For each hardware ITS create and initialize a virtual ITS for Dom0. We use the same memory mapped address to keep the doorbell working. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 32 xen/arch/arm/vgic-v3.c

[Xen-devel] [PATCH v4 23/27] ARM: vITS: handle INV command

The INV command instructs the ITS to update the configuration data for a given LPI by re-reading its entry from the property table. We don't need to care so much about the priority value, but enabling or disabling an LPI has some effect: We remove or push virtual LPIs to their VCPUs, also check

[Xen-devel] [PATCH v4 21/27] ARM: vITS: handle MOVI command

The MOVI command moves the interrupt affinity from one redistributor (read: VCPU) to another. For now migration of "live" LPIs is not yet implemented, but we store the changed affinity in the host LPI structure and in our virtual ITTE. Signed-off-by: Andre Przywara ---

[Xen-devel] [PATCH v4 13/27] ARM: vGICv3: Handle disabled LPIs

If a guest disables an LPI, we do not forward this to the associated host LPI to avoid queueing commands to the host ITS command queue. So it may happen that an LPI fires nevertheless on the host. In this case we can bail out early, but have to save the pending state on the virtual side.

[Xen-devel] [PATCH v4 24/27] ARM: vITS: handle INVALL command

The INVALL command instructs an ITS to invalidate the configuration data for all LPIs associated with a given redistributor (read: VCPU). This is nasty to emulate exactly with our architecture, so we just scan the pending table and inject _every_ LPI found there that got enabled. Signed-off-by:

[Xen-devel] [PATCH v4 00/27] arm64: Dom0 ITS emulation

Hi, I managed to go over the remaining emails I couldn't finish on Friday. This series is the result of this and has about 30 smaller fixes, see the changelog below. This should address all comments Stefano had. There are a few things my brain cannot cope with today anymore, so I will address

[Xen-devel] [PATCH v4 20/27] ARM: vITS: handle MAPTI command

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU pair and actually instantiates LPI interrupts. We connect the already allocated host LPI to this virtual LPI, so that any triggering IRQ on the host can be quickly forwarded to a guest. Beside entering the VCPU and the virtual

[Xen-devel] [PATCH v4 14/27] ARM: vGICv3: introduce basic ITS emulation bits

Create a new file to hold the emulation code for the ITS widget. For now we emulate the memory mapped ITS registers and provide a stub to introduce the ITS command handling framework (but without actually emulating any commands at this time). Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v4 22/27] ARM: vITS: handle DISCARD command

The DISCARD command drops the connection between a DeviceID/EventID and an LPI/collection pair. We mark the respective structure entries as not allocated and make sure that any queued IRQs are removed. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 30

[Xen-devel] [PATCH v4 10/27] ARM: GICv3: forward pending LPIs to guests

Upon receiving an LPI, we need to find the right VCPU and virtual IRQ number to get this IRQ injected. Iterate our two-level LPI table to find this information quickly when the host takes an LPI. Call the existing injection function to let the GIC emulation deal with this interrupt.

[Xen-devel] [PATCH v4 05/27] ARM: GICv3 ITS: map ITS command buffer

Instead of directly manipulating the tables in memory, an ITS driver sends commands via a ring buffer in normal system memory to the ITS h/w to create or alter the LPI mappings. Allocate memory for that buffer and tell the ITS about it to be able to send ITS commands. Signed-off-by: Andre

[Xen-devel] [PATCH v4 09/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. We only care about mapped LPIs, so we can get away with having struct pending_irq's only for them. Maintain a radix tree per domain where we

[Xen-devel] [PATCH v4 03/27] ARM: GICv3: allocate LPI pending and property table

The ARM GICv3 provides a new kind of interrupt called LPIs. The pending bits and the configuration data (priority, enable bits) for those LPIs are stored in tables in normal memory, which software has to provide to the hardware. Allocate the required memory, initialize it and hand it over to each

[Xen-devel] [PATCH v4 04/27] ARM: GICv3 ITS: allocate device and collection table

Each ITS maps a pair of a DeviceID (for instance derived from a PCI b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a pair of LPI number and collection ID, which points to the target CPU. This mapping is stored in the device and collection tables, which software has to provide

[Xen-devel] [PATCH v4 11/27] ARM: GICv3: enable ITS and LPIs on the host

Now that the host part of the ITS code is in place, we can enable the ITS and also LPIs on each redistributor to get the show rolling. At this point there would be no LPIs mapped, as guests don't know about the ITS yet. Signed-off-by: Andre Przywara ---

[Xen-devel] [PATCH v4 18/27] ARM: vITS: handle MAPC command

The MAPC command associates a given collection ID with a given redistributor, thus mapping collections to VCPUs. We just store the vcpu_id in the collection table for that. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 46

[Xen-devel] [PATCH v4 17/27] ARM: vITS: handle INT command

The INT command sets a given LPI identified by a DeviceID/EventID pair as pending and thus triggers it to be injected. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 30 ++ 1 file changed, 30 insertions(+) diff --git

[Xen-devel] [PATCH v4 07/27] ARM: GICv3 ITS: introduce host LPI array

The number of LPIs on a host can be potentially huge (millions), although in practise will be mostly reasonable. So prematurely allocating an array of struct irq_desc's for each LPI is not an option. However Xen itself does not care about LPIs, as every LPI will be injected into a guest (Dom0 for

[Xen-devel] [PATCH v4 08/27] ARM: GICv3 ITS: introduce device mapping

The ITS uses device IDs to map LPIs to a device. Dom0 will later use those IDs, which we directly pass on to the host. For this we have to map each device that Dom0 may request to a host ITS device with the same identifier. Allocate the respective memory and enter each device into an rbtree to

[Xen-devel] [PATCH v4 02/27] ARM: GICv3 ITS: initialize host ITS

Map the registers frame for each host ITS and populate the host ITS structure with some parameters describing the size of certain properties like the number of bits for device IDs. Introduce a command line parameter to limit the number of devices Xen should handle. This defaults to the value

[Xen-devel] [PATCH v4 27/27] ARM: vGIC: advertise LPI support

To let a guest know about the availability of virtual LPIs, set the respective bits in the virtual GIC registers and let a guest control the LPI enable bit. Only report the LPI capability if the host has initialized at least one ITS. Signed-off-by: Andre Przywara ---

[Xen-devel] [PATCH v4 19/27] ARM: vITS: handle MAPD command

The MAPD command maps a device by associating a memory region for storing ITEs with a certain device ID. We store the given guest physical address in the device table, and, if this command comes from Dom0, tell the host ITS driver about this new mapping, so it can issue the corresponing host MAPD

[Xen-devel] [PATCH v4 26/27] ARM: vITS: create ITS subnodes for Dom0 DT

Dom0 expects all ITSes in the system to be propagated to be able to use MSIs. Create Dom0 DT nodes for each hardware ITS, keeping the register frame address the same, as the doorbell address that the Dom0 drivers program into the BARs has to match the hardware. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v4 16/27] ARM: vITS: handle CLEAR command

This introduces the ITS command handler for the CLEAR command, which clears the pending state of an LPI. This removes a not-yet injected, but already queued IRQ from a VCPU. As read_itte() is now eventually used, we add the static keyword. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v4 15/27] ARM: vITS: introduce translation table walks

The ITS stores the target (v)CPU and the (virtual) LPI number in tables. Introduce functions to walk those tables and translate an device ID - event ID pair into a pair of virtual LPI and vCPU. We map those tables on demand - which is cheap on arm64. Also we take care of the locking on the way,

[Xen-devel] [PATCH v4 12/27] ARM: vGICv3: handle virtual LPI pending and property tables

Allow a guest to provide the address and size for the memory regions it has reserved for the GICv3 pending and property tables. We sanitise the various fields of the respective redistributor registers and map those pages into Xen's address space to have easy access. Signed-off-by: Andre Przywara

Re: [Xen-devel] [PATCH v2 08/27] ARM: GICv3 ITS: introduce host LPI array

On 04/03/2017 08:30 PM, Andre Przywara wrote: Hi, Hi Andre, On 23/03/17 19:08, Julien Grall wrote: /* + * On the host ITS @its, map @nr_events consecutive LPIs. + * The mapping connects a device @devid and event @eventid pair to LPI @lpi, + * increasing both @eventid and @lpi to cover the

Re: [Xen-devel] [PATCH v2 06/27] ARM: GICv3 ITS: introduce device mapping

Hi, On 22/03/17 17:29, Julien Grall wrote: > Hi Andre, > > On 16/03/17 11:20, Andre Przywara wrote: >> The ITS uses device IDs to map LPIs to a device. Dom0 will later use >> those IDs, which we directly pass on to the host. >> For this we have to map each device that Dom0 may request to a host

Re: [Xen-devel] [GSoc] GSoc Introduction : Xen on ARM: create multiple guests from device tree

Hi Stefano, I have asked questions in inline. Clarification below questions would really help me in contribution. Please look into the questions. I am highlighting them in this mail. For example, Dom1 should be able to share a page with Dom2 and a different page with Dom3. It needs to be

[Xen-devel] [xen-4.6-testing test] 107151: tolerable FAIL - PUSHED

flight 107151 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/107151/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106819

Re: [Xen-devel] [PATCH v2] setup vwfi correctly on cpu0

Hi Stefano, On 03/31/2017 11:37 PM, Stefano Stabellini wrote: parse_vwfi runs after init_traps on cpu0, potentially resulting in the wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their case init_traps will write the correct set of flags to HCR_EL2. For cpu0, fix the issue

Re: [Xen-devel] [PATCH v2 06/27] ARM: GICv3 ITS: introduce device mapping

Hi, On 22/03/17 22:45, Stefano Stabellini wrote: > On Thu, 16 Mar 2017, Andre Przywara wrote: >> The ITS uses device IDs to map LPIs to a device. Dom0 will later use >> those IDs, which we directly pass on to the host. >> For this we have to map each device that Dom0 may request to a host >> ITS

Re: [Xen-devel] [PATCH] setup vwfi correctly on cpu0

On Mon, 3 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 31/03/17 23:33, Stefano Stabellini wrote: > > On Fri, 31 Mar 2017, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 03/30/2017 11:35 PM, Stefano Stabellini wrote: > > > > parse_vwfi runs after init_traps on cpu0, potentially

Re: [Xen-devel] [PATCH v3 03/26] ARM: GICv3 ITS: allocate device and collection table

Hi, On 03/04/17 18:22, Julien Grall wrote: > Hi Andre, > > On 03/04/17 16:38, Julien Grall wrote: >> On 31/03/17 19:05, Andre Przywara wrote: >>> Each ITS maps a pair of a DeviceID (for instance derived from a PCI >>> b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a >>> pair

Re: [Xen-devel] [GSoc] GSoc Introduction : Xen on ARM: create multiple guests from device tree

Thank you! I am looking forward to your contribution on the list! If you encounter any issues, please let us know. The code contribution is more important, but if you find the time in the next few days, it would be nice to add more details to the implementation plan, such as where the memory gets

Re: [Xen-devel] [PATCH v2 08/27] ARM: GICv3 ITS: introduce host LPI array

Hi, On 23/03/17 19:08, Julien Grall wrote: > Hi Andre, > > On 16/03/17 11:20, Andre Przywara wrote: >> The number of LPIs on a host can be potentially huge (millions), >> although in practise will be mostly reasonable. So prematurely allocating >> an array of struct irq_desc's for each LPI is

Re: [Xen-devel] [PATCH] x86/vpmu_intel: Handle SMT consistently for programmable and fixed counters

On 04/03/2017 06:36 AM, Jan Beulich wrote: On 31.03.17 at 16:46, wrote: This patch masks .AnyThread bits in IA32_FIXED_CTR_CTRL MSR for all versions of Intel Arhcitectural Performance Monitoring. Note that .AnyThread bit (21) is already masked in IA32_PERFEVTSELx

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

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

Re: [Xen-devel] [PATCH v3 06/26] ARM: GICv3 ITS: introduce device mapping

Hi Andre, Mostly repeating my comments from the previous version. On 31/03/17 19:05, Andre Przywara wrote: [...] +static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid, + uint8_t size_bits, paddr_t itt_addr, bool valid) +{ +uint64_t cmd[4]; + +

Re: [Xen-devel] [PATCH v2 20/27] ARM: vITS: handle MAPTI command

Hi, On 24/03/17 14:54, Julien Grall wrote: > Hi Andre, > > On 03/16/2017 11:20 AM, Andre Przywara wrote: >> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU >> pair and actually instantiates LPI interrupts. >> We connect the already allocated host LPI to this virtual LPI, so

Re: [Xen-devel] [PATCH RFC] x86/emulate: implement hvmemul_cmpxchg() with an actual CMPXCHG

On 04/03/2017 09:20 PM, Razvan Cojocaru wrote: > On 04/01/2017 07:56 PM, Razvan Cojocaru wrote: >> On 03/31/2017 06:04 PM, Jan Beulich wrote: >> On 31.03.17 at 17:01, wrote: On 03/31/2017 05:46 PM, Jan Beulich wrote: On 31.03.17 at 11:56,

Re: [Xen-devel] [PATCH v3 06/26] ARM: GICv3 ITS: introduce device mapping

On 01/04/17 09:01, Vijay Kilari wrote: Hi Andre, Hi Vijay, On Fri, Mar 31, 2017 at 11:35 PM, Andre Przywara wrote: +/* An Interrupt Translation Table needs to be 256-byte aligned. */ +itt_addr = _xzalloc(nr_events * hw_its->itte_size, 256); As I

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

Hi, Andrew On Mon, Apr 3, 2017 at 7:42 PM, Andrew Cooper wrote: > On 03/04/17 17:24, Oleksandr Tyshchenko wrote: >> Hi, all. >> >> Playing with non-shared IOMMU in Xen on ARM I faced one interesting >> thing. I found out that the superpages were shattered during domain

Re: [Xen-devel] [PATCH v8 2/4] xen: introduce a C99 headers check

On Mon, 3 Apr 2017, Jan Beulich wrote: > >>> On 31.03.17 at 21:15, wrote: > > Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h > > and pvcalls.h. > > > > In addition to the usual -include stdint.h, also add -include string.h > > to the C99 check to

Re: [Xen-devel] [PATCH v2 15/27] ARM: vITS: introduce translation table walks

Hi, On 24/03/17 13:00, Julien Grall wrote: > Hi Andre, > > On 03/16/2017 11:20 AM, Andre Przywara wrote: >> The ITS stores the target (v)CPU and the (virtual) LPI number in tables. >> Introduce functions to walk those tables and translate an device ID - >> event ID pair into a pair of virtual

Re: [Xen-devel] [PATCH RFC] x86/emulate: implement hvmemul_cmpxchg() with an actual CMPXCHG

On 04/01/2017 07:56 PM, Razvan Cojocaru wrote: > On 03/31/2017 06:04 PM, Jan Beulich wrote: > On 31.03.17 at 17:01, wrote: >>> On 03/31/2017 05:46 PM, Jan Beulich wrote: >>> On 31.03.17 at 11:56, wrote: > On 03/31/2017 10:34 AM,

Re: [Xen-devel] [PATCH v3 02/26] ARM: GICv3: allocate LPI pending and property table

On Mon, 3 Apr 2017, Andre Przywara wrote: > Hi, > > On 31/03/17 23:59, Stefano Stabellini wrote: > > On Fri, 31 Mar 2017, Andre Przywara wrote: > >> The ARM GICv3 provides a new kind of interrupt called LPIs. > >> The pending bits and the configuration data (priority, enable bits) for > >> those

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

Hi Andrew, On 03/04/17 18:16, Andrew Cooper wrote: On 03/04/17 18:02, Julien Grall wrote: Hi Andrew, On 03/04/17 17:42, Andrew Cooper wrote: On 03/04/17 17:24, Oleksandr Tyshchenko wrote: Hi, all. Playing with non-shared IOMMU in Xen on ARM I faced one interesting thing. I found out that

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

On 29/03/17 12:06, Vitaly Kuznetsov wrote: > Juergen Gross writes: >> I'll create another branch for-linus-4.12 based on the tip tree next >> week which will be subject to the pull request for Linus. As soon as >> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be

Re: [Xen-devel] [PATCH] kexec: clear kexec_image slot when unloading kexec image

On Mon, Apr 03, 2017 at 10:44:54AM -0700, Bhavesh Davda wrote: > While theoretically this bug can be tickled simply by a sequence of 'kexec -p' > to load a kexec crash image followed by two back-to-back 'kexec -p -u' to > unload the kexec crash image, I found the following perl script to be useful

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

On Mon, Apr 3, 2017 at 8:39 PM, Oleksandr Tyshchenko wrote: > Hi, Julien. > > On Mon, Apr 3, 2017 at 8:02 PM, Julien Grall wrote: >> Hi Andrew, >> >> >> On 03/04/17 17:42, Andrew Cooper wrote: >>> >>> On 03/04/17 17:24, Oleksandr Tyshchenko wrote:

[Xen-devel] [PATCH] kexec: clear kexec_image slot when unloading kexec image

While theoretically this bug can be tickled simply by a sequence of 'kexec -p' to load a kexec crash image followed by two back-to-back 'kexec -p -u' to unload the kexec crash image, I found the following perl script to be useful to reliably reproduce Xen panics as well as verify that the fix

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

Hi, Julien. On Mon, Apr 3, 2017 at 8:02 PM, Julien Grall wrote: > Hi Andrew, > > > On 03/04/17 17:42, Andrew Cooper wrote: >> >> On 03/04/17 17:24, Oleksandr Tyshchenko wrote: >>> >>> Hi, all. >>> >>> Playing with non-shared IOMMU in Xen on ARM I faced one interesting >>>

Re: [Xen-devel] [PATCH for 4.9 3/6] x86/hvm: Fix segmentation logic for system segments

On 03/04/17 17:08, Jan Beulich wrote: On 03.04.17 at 17:42, wrote: >> On 03/04/17 16:07, Jan Beulich wrote: >> On 03.04.17 at 16:27, wrote: On 03/04/17 10:13, Jan Beulich wrote: On 31.03.17 at 21:50,

Re: [Xen-devel] [PATCH v3 03/26] ARM: GICv3 ITS: allocate device and collection table

Hi Andre, On 03/04/17 16:38, Julien Grall wrote: On 31/03/17 19:05, Andre Przywara wrote: Each ITS maps a pair of a DeviceID (for instance derived from a PCI b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a pair of LPI number and collection ID, which points to the target

Re: [Xen-devel] How to migrate vCPUs based on Credit Scheduler

Adding George, Dario & Anshul Lars > On 3 Apr 2017, at 17:21, 甘清甜 wrote: > > Hi, > > I'm now designing new vCPU scheduler in Xen, and trying to implement > the scheduler based on the Credit scheduler in Xen-4.5.1. But I encountered > come problems when debuging the

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

On 03/04/17 18:02, Julien Grall wrote: > Hi Andrew, > > On 03/04/17 17:42, Andrew Cooper wrote: >> On 03/04/17 17:24, Oleksandr Tyshchenko wrote: >>> Hi, all. >>> >>> Playing with non-shared IOMMU in Xen on ARM I faced one interesting >>> thing. I found out that the superpages were shattered

[Xen-devel] Random Dom0 Warning when starting PV guest

Hello, I'm getting some random kernel warnings on dom0 boot that I'm concerned about. Here is some information for my host and guest machines. I got both xen and kernel from CentOS 6.8 xen4centos. Dom0: - xen-4.6.1-11.el6.x86_64 - kernel-3.18.34-20.el6.x86_64 PV Guest: -

[Xen-devel] [PATCH] libxc: fix segfault on uninitialized xch->fmem

Currently in xc_interface_open, xch->fmem is not initialized and in some rare case the code fails before ever assigning a value to it. I got this in master: $ sudo ./xl/xl run xencall: error: Could not obtain handle on privileged command interface: No such file or directory

[Xen-devel] How to migrate vCPUs based on Credit Scheduler

Hi, I'm now designing new vCPU scheduler in Xen, and trying to implement the scheduler based on the Credit scheduler in Xen-4.5.1. But I encountered come problems when debuging the code. Most of the code modification is done in function csched_schedule() in file: xen/common/csched_schedule.c .

Re: [Xen-devel] Shattering superpages impact on IOMMU in Xen

Hi Andrew, On 03/04/17 17:42, Andrew Cooper wrote: On 03/04/17 17:24, Oleksandr Tyshchenko wrote: Hi, all. Playing with non-shared IOMMU in Xen on ARM I faced one interesting thing. I found out that the superpages were shattered during domain life cycle. This is the result of mapping of

[Xen-devel] [PATCH v2 2/9] mm: Place unscrubbed pages at the end of pagelist

. so that it's easy to find pages that need to be scrubbed (those pages are now marked with _PGC_need_scrub bit). Signed-off-by: Boris Ostrovsky --- Changes in v2: * Added page_list_add_scrub() * Mark pages as needing a scrub irrespective on tanted in

  1   2   3   >