[Xen-devel] [libvirt test] 105075: regressions - FAIL

flight 105075 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/105075/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 5 xen-install fail REGR. vs. 104989 Regressions which are

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

flight 105038 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105038/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254 test-amd64-i386-xl

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

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

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

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

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

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

Re: [Xen-devel] [PATCH v1 0/7] Make building xSplice patches easier

On 5/6/16 10:48 AM, Ross Lagerwall wrote: > Here is a set of changes to make building xSplice patches easier. > Tested to boot on x86. > Compile-tested on arm. > > This is probably too late to make it into 4.7, but hey, if someone wants > to put it in I've CC'd Wei. Ross, What happened with

Re: [Xen-devel] [PATCH RESEND v5 04/24] x86: refactor psr: implement CPU init and free flow.

On Thu, Jan 19, 2017 at 02:01:06PM +0800, Yi Sun wrote: > This patch implements the CPU init and free flow including L3 CAT > initialization and feature list free. > > Signed-off-by: Yi Sun > --- > v5: > - modify commit message beacuse of code changes. > - add

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

flight 105047 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105047/ 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] [ovmf test] 105046: all pass - PUSHED

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

Re: [Xen-devel] [linux-linus test] 105012: regressions - FAIL

On 01/30/2017 04:51 PM, osstest service owner wrote: flight 105012 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105012/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl 17

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

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

[Xen-devel] [qemu-mainline test] 105016: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH RESEND v5 02/24] x86: refactor psr: remove L3 CAT/CDP codes.

On Thu, Jan 19, 2017 at 02:01:04PM +0800, Yi Sun wrote: > The current cache allocation codes in psr.c do not consider > future features addition and are not friendly to extend. > > To make psr.c be more flexible to add new features and fulfill > the program principle, open for extension but

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

flight 105012 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105012/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl 17 guest-localmigrate/x10fail REGR. vs. 59254

[Xen-devel] [linux-linus bisection] complete test-armhf-armhf-xl-multivcpu

branch xen-unstable xenbranch xen-unstable job test-armhf-armhf-xl-multivcpu testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree:

Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

On Mon, 30 Jan 2017, Tamas K Lengyel wrote: > On Mon, Jan 30, 2017 at 9:01 AM, Julien Grall wrote: > > Hi Stefano, > > > > On 27/01/17 23:53, Stefano Stabellini wrote: > >> > >> On Fri, 27 Jan 2017, Julien Grall wrote: > >>> > >>> On 27/01/2017 20:41, Stefano Stabellini

Re: [Xen-devel] [PATCH v2 2/2] p2m: split mem_access into separate files

On Fri, 9 Dec 2016, Tamas K Lengyel wrote: > This patch relocates mem_access components that are currently mixed with p2m > code into separate files. This better aligns the code with similar subsystems, > such as mem_sharing and mem_paging, which are already in separate files. There > are no

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

On Fri, 9 Dec 2016, Tamas K Lengyel wrote: > The only caller of this function is get_page_from_gva which already takes > a vcpu pointer as input. Pass this along to make the function in-line with > its intended use-case. > > Signed-off-by: Tamas K Lengyel

[Xen-devel] [RFC v2] Device memory mappings for Dom0 on ARM64 ACPI systems

Hi all, a couple of weeks ago I sent a detailed email asking for feedback on a problem with Linux on Xen on ACPI systems: http://marc.info/?l=linux-arm-kernel=148469169210500=2 In short, on BUS_NOTIFY_ADD_DEVICE events, Linux (as Dom0) requests stage-2 MMIO regions mappings via hypercall to

Re: [Xen-devel] [PATCH RESEND v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

> > +# Testing > > + > > +L2 CAT uses same xl interfaces as L3 CAT/CDP. So, we can execute these > > +commands to verify L2 CAT and L3 CAT/CDP on different HWs support them. > > + > > +For example: > > +root@:~$ xl psr-hwinfo --cat > > +Cache Allocation Technology (CAT): L2 > > +Socket

[Xen-devel] [xtf test] 105019: all pass - PUSHED

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

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

On 01/30/2017 02:06 PM, Eric Dumazet wrote: > On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote: > >> We do netif_carrier_off() first thing in xennet_disconnect_backend() and >> the only place where the timer is rearmed is xennet_alloc_rx_buffers(), >> which is guarded by netif_carrier_ok()

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote: > We do netif_carrier_off() first thing in xennet_disconnect_backend() and > the only place where the timer is rearmed is xennet_alloc_rx_buffers(), > which is guarded by netif_carrier_ok() check. Oh well, testing netif_carrier_ok() in

Re: [Xen-devel] [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table

George / Tamas, I'm away from my dev machine so I cannot test. Thank you both for working so quickly to resolve this behavior! Best regards, --Matt On 01/30/2017 11:07 AM, Tamas K Lengyel wrote: > Hi George, > yeap, this solves old mem_access settings being triggered when I > recreate altp2m

[Xen-devel] [PATCH 25/28] 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 22/28] 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 26/28] 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 | 28 xen/arch/arm/vgic-v3.c

[Xen-devel] [PATCH 13/28] 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

[Xen-devel] [PATCH 28/28] ARM: vGIC: advertising 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 24/28] 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 18/28] 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 | 23 +++ 1 file changed, 23 insertions(+) diff --git

[Xen-devel] [PATCH 11/28] 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 17/28] 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. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 35

[Xen-devel] [PATCH 23/28] 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 | 33

[Xen-devel] [PATCH 12/28] 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 15/28] 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 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

To get MSIs from devices forwarded to a CPU, we need to name the device and its MSIs by mapping them to an ITS. Since this involves queueing commands to the ITS command queue, we can't really afford to do this during the guest's runtime, as this would open up a denial-of-service attack vector. So

[Xen-devel] [PATCH 27/28] 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 14/28] 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 21/28] 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. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH 16/28] 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. Since the final interrupt translation tables can be smaller than a page, we map them on demand (which is

[Xen-devel] [PATCH 19/28] 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 | 30 ++

[Xen-devel] [PATCH 20/28] ARM: vITS: handle MAPD command

The MAPD command maps a device by associating a memory region for storing ITTEs with a certain device ID. We just store the given guest physical address in the device table. We don't map the device tables permanently, as their alignment requirement is only 256 Bytes, thus making mapping of several

[Xen-devel] [PATCH 08/28] 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 07/28] 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 06/28] 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 04/28] ARM: GICv3 ITS: allocate device and collection table

Each ITS maps a pair of a DeviceID (usually the 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 for the ITS to

[Xen-devel] [PATCH 03/28] 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 05/28] ARM: GICv3 ITS: map ITS command buffer

Instead of directly manipulating the tables in memory, an ITS driver sends commands via a ring buffer 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 Przywara

[Xen-devel] [PATCH 02/28] 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 10/28] 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. However we actually only need those when an interrupt is on a vCPU (or is about to be injected). Maintain a list of those structs that we can

[Xen-devel] [PATCH 01/28] ARM: export __flush_dcache_area()

The ability to clean a cache line is not only useful for EFI, but will be needed later for the ITS support. Export the function to be usable from the whole Xen/ARM code. Signed-off-by: Andre Przywara --- xen/arch/arm/efi/efi-boot.h | 1 - xen/include/asm-arm/cache.h | 4

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

Hi, after the two RFC versions now the first "serious" attempt for emulating an ARM GICv3 ITS interrupt controller, for Dom0 only at the moment. The ITS is an interrupt controller widget providing a sophisticated way of dealing with MSIs in a scalable manner. For hardware which relies on the ITS

[Xen-devel] [PATCH] acpi: Switch to dynamic mapping at SYS_STATE_boot

We can switch ACPI from using fixmap to dynamic mapping as soon as the system enters SYS_STATE_boot. This will allow us, for example, to map MADT on systems with large number of processors where the table might not fit into NUM_FIXMAP_ACPI_PAGES (currently set to 4). Signed-off-by: Boris

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

On 01/30/2017 01:07 PM, Eric Dumazet wrote: > On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote: >> rx_refill_timer should be deleted as soon as we disconnect from the >> backend since otherwise it is possible for the timer to go off before >> we get to xennet_destroy_queues(). If this

Re: [Xen-devel] [PATCH RESEND v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

On Thu, Jan 19, 2017 at 02:01:03PM +0800, Yi Sun wrote: > This patch creates L2 CAT feature document in doc/features/. > It describes details of L2 CAT. Perhaps also mention what is the title in the Intel SDM to look into as well? Perhaps: "See Intel Resource Director Technology Monitoring

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote: > rx_refill_timer should be deleted as soon as we disconnect from the > backend since otherwise it is possible for the timer to go off before > we get to xennet_destroy_queues(). If this happens we may dereference > queue->rx.sring which is

Re: [Xen-devel] [PATCH 2/2] x86/vmx: Drop ept_get_*() helpers

On 30/01/17 16:54, Andrew Cooper wrote: > The ept_get_*() helpers are not used consistently, and are more verbose than > the code they wrap. Drop the wrappers and use the internal union names > consistently. > > While making these adjustments, drop the redundant ept_* prefix from mt, wl > and

[Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

rx_refill_timer should be deleted as soon as we disconnect from the backend since otherwise it is possible for the timer to go off before we get to xennet_destroy_queues(). If this happens we may dereference queue->rx.sring which is set to NULL in xennet_disconnect_backend(). Signed-off-by: Boris

[Xen-devel] [PATCH 1/2] x86/mm: Plumb a error return through {paging, hap, shadow}_vcpu_init()

No functional change yet, but required for subsequent changes. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Tim Deegan CC: George Dunlap --- xen/arch/x86/domain.c | 3 ++-

[Xen-devel] [PATCH 2/2] x86/shadow: Move shadow pagetable fields into struct shadow_vcpu

The vTLB and last_write* booleans are used exclusively by the shadow pagetable code. Move them from paging_vcpu to shadow_vcpu, which causes them to be entirely omitted on a build without shadow paging support. While changing the qualified names of these variables, drop an unnessary NULL check

[Xen-devel] [RFC v1 1/6] xen/arm: traps: Reorder early overwrite of FID

From: "Edgar E. Iglesias" Move the early setting of PSCI_RESULT_REG to a later stage avoiding the early override of the FID that's stored in the same register. No functional change. Signed-off-by: Edgar E. Iglesias ---

[Xen-devel] [RFC v1 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

From: "Edgar E. Iglesias" Allow platform_hvc to handle guest SMC calls (as well as HVC calls) in a platform specific way. Signed-off-by: Edgar E. Iglesias --- xen/arch/arm/traps.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Xen-devel] [RFC v1 5/6] xen/arm: zynqmp: Forward plaform specific firmware calls

From: "Edgar E. Iglesias" Forward platform specific firmware calls from the hardware domain to firmware. Signed-off-by: Edgar E. Iglesias --- xen/arch/arm/platforms/xilinx-zynqmp.c | 63 ++ 1 file changed,

[Xen-devel] [RFC v1 6/6] xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node

From: "Edgar E. Iglesias" Stop blacklisting ZynqMP's power management node. This is now possible since we allow the hardware domain to issue HVC/SMC calls to firmware. Signed-off-by: Edgar E. Iglesias ---

[Xen-devel] [RFC v1 4/6] xen/arm: Introduce call_smcc64

From: "Edgar E. Iglesias" Introduce call_smcc64, a helper function to issue 64-bit SMC calls that follow the SMC Calling Convention. This includes returning up to 4 64-bit values. Signed-off-by: Edgar E. Iglesias ---

[Xen-devel] [RFC v1 0/6] zynqmp: Add forwarding of platform specific firmware calls

From: "Edgar E. Iglesias" The ZynqMP software stack has an extensive Firmware API. Software at EL1 is increasingly dependant on this API. In fact, a large set of use-cases for Linux already require access to firmware. In a couple of months, we expect that most setups

[Xen-devel] [RFC v1 2/6] xen/arm: Introduce platform_hvc

From: "Edgar E. Iglesias" Introduce platform_hvc as a way to handle hypercalls that Xen does not know about in a platform specific way. This is particularly useful for implementing the SiP (SoC implementation specific) service calls. Signed-off-by: Edgar E. Iglesias

Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

On Mon, Jan 30, 2017 at 9:01 AM, Julien Grall wrote: > Hi Stefano, > > On 27/01/17 23:53, Stefano Stabellini wrote: >> >> On Fri, 27 Jan 2017, Julien Grall wrote: >>> >>> On 27/01/2017 20:41, Stefano Stabellini wrote: On Fri, 27 Jan 2017, Tamas K Lengyel wrote: >>>

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/30/2017 09:06 AM, Boris Ostrovsky wrote: On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote: 2. It tickles a latent bug during resume where the timer triggers before we re-connect. The trouble is that we now try to dereference queue->rx.sring which is NULL since we disconnect in

Re: [Xen-devel] [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table

Hi George, yeap, this solves old mem_access settings being triggered when I recreate altp2m views. Thanks! On Mon, Jan 30, 2017 at 8:17 AM, George Dunlap wrote: > Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of > nested p2m tables whenever the host p2m

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote: > >> 2. It tickles a latent bug during resume where the timer triggers >> before we re-connect. The trouble is that we now try to dereference >> queue->rx.sring which is NULL since we disconnect in >> netfront_resume(). (Curiously, I only

[Xen-devel] [PATCH 2/2] x86/vmx: Drop ept_get_*() helpers

The ept_get_*() helpers are not used consistently, and are more verbose than the code they wrap. Drop the wrappers and use the internal union names consistently. While making these adjustments, drop the redundant ept_* prefix from mt, wl and ad, and rename the asr field to mfn for consistency

[Xen-devel] [PATCH 1/2] x86/vmx: Introduce a bitfield structure for EPT_VIOLATION EXIT_QUALIFICATIONs

This results in rather more readable code. No functional change. All fields currently specified are included, but commented out as no support for their use is present. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/29/2017 03:09 PM, Boris Ostrovsky wrote: There are couple of problems with this patch. 1. The 'if' clause now evaluates to true on pretty much every call to xennet_alloc_rx_buffers(). Thanks for catching this. In my testing I did not notice this - mostly because of the nature of the

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

flight 105021 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105021/ 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] Xen 4.9 Development Update

On Mon, Jan 30, 2017 at 03:33:19PM +, Julien Grall wrote: > > == Testing == > > * Continuous fuzzing of Xen code using Google oss-fuzz > - Wei Liu > Stuck as we need someone to write the code to integrate things into oss-fuzz. Wei. ___

Re: [Xen-devel] [PATCH v4] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

Hi Stefano, On 27/01/17 23:53, Stefano Stabellini wrote: On Fri, 27 Jan 2017, Julien Grall wrote: On 27/01/2017 20:41, Stefano Stabellini wrote: On Fri, 27 Jan 2017, Tamas K Lengyel wrote: For the second instance, we have no other choice. Most alloc_heap_pages (alloc_xenheap_pages and

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: use qdev_unplug() insteda of g_free() in xen_pv_find_xendev()

On 30/01/17 16:46, Peter Maydell wrote: > On 30 January 2017 at 15:14, Juergen Gross wrote: >> The error exits of xen_pv_find_xendev() free the new xen-device via >> g_free() which is wrong. >> >> As the xen-device has been initialized as qdev it must be removed >> via

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: use qdev_unplug() insteda of g_free() in xen_pv_find_xendev()

On 30 January 2017 at 15:14, Juergen Gross wrote: > The error exits of xen_pv_find_xendev() free the new xen-device via > g_free() which is wrong. > > As the xen-device has been initialized as qdev it must be removed > via qdev_unplug(). > > This bug has been introduced with

Re: [Xen-devel] Xen 4.9 Development Update

On Mon, Jan 30, 2017 at 03:32:49PM +, Julien Grall wrote: [...] > > > > > > > > I think it would be good to main two lists. One of "the stuff people > > > > are working on overall", and "the subset of it intended/expected for the > > > > forthcoming release". > > > > > > > > Stuff will

[Xen-devel] [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table

Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of nested p2m tables whenever the host p2m table changed. Unfortunately in the process, it added a filter to the generic p2m_flush_table() function so that the p2m would only be flushed if it was being used as a nested p2m. This

[Xen-devel] Xen 4.9 Development Update

This email only tracks big items for xen.git tree. Please reply for items you woulk like to see in 4.9 so that people have an idea what is going on and prioritise accordingly. You're welcome to provide description and use cases of the feature you're working on. = Timeline = We now adopt a fixed

Re: [Xen-devel] Xen 4.9 Development Update

Hi, On 26/01/17 17:06, Wei Liu wrote: On Thu, Jan 26, 2017 at 12:27:15PM +, Julien Grall wrote: Hi, On 09/12/2016 19:09, Andrew Cooper wrote: On 09/12/16 19:01, Stefano Stabellini wrote: On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote: On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:

Re: [Xen-devel] [PATCH] VT-d/RMRR: Avoid memory corruption in add_user_rmrr()

Jan, Sure. I will look in to it. Venu > -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, January 30, 2017 04:39 AM > To: Andrew Cooper; Elena Ufimtseva; Venu Busireddy > Cc: Xen-devel > Subject: Re: [PATCH] VT-d/RMRR: Avoid memory corruption in

[Xen-devel] [PATCH] xen: use qdev_unplug() insteda of g_free() in xen_pv_find_xendev()

The error exits of xen_pv_find_xendev() free the new xen-device via g_free() which is wrong. As the xen-device has been initialized as qdev it must be removed via qdev_unplug(). This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6 ("xen: create qdev for each backend device").

[Xen-devel] [PATCH v3] xen, input: try to read screen resolution for xen-kbdfront

Instead of using the default resolution of 800*600 for the pointing device of xen-kbdfront try to read the resolution of the (virtual) framebuffer device. Use the default as fallback only. Signed-off-by: Juergen Gross --- V3: add case of late framebuffer registration (Oleksandr

[Xen-devel] [PATCH] xl: Fix assertion on domain reboot with new configuration

libxl_domain_build_info_dispose is not resetting the type field to LIBXL_DOMAIN_TYPE_INVALID. Instead, it is memseting the struct to 0 thus when libxl_domain_build_info_init_type is called after a dispose on the same struct, an assertion is triggered because type != LIBXL_DOMAIN_TYPE_INVALID.

[Xen-devel] [PATCH] xl: Fix segfault on domain reboot

If we have no disk attached at startup, diskws is left unallocated but `d_config.num_disks` may change if we attach a disk later. When a domain is rebooted `evdisable_disk_ejects` is called this will later result in a segfault if num_disks has changed. Expand diskws when num_disks increases.

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

On Mon, Jan 30, 2017 at 07:24:57AM -0700, Jan Beulich wrote: > >>> On 30.01.17 at 15:17, wrote: > > On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote: > >> >>> On 30.01.17 at 13:46, wrote: > >> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

>>> On 30.01.17 at 15:17, wrote: > On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote: >> >>> On 30.01.17 at 13:46, wrote: >> > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote: >> >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

On Mon, Jan 30, 2017 at 07:14:23AM -0700, Jan Beulich wrote: > >>> On 30.01.17 at 13:46, wrote: > > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote: > >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote: > >> > >>> On 25.01.17 at 16:44,

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

flight 105009 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105009/ 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 3/7] x86: extract macros to x86-defns.h

>>> On 30.01.17 at 13:46, wrote: > On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote: >> On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote: >> > >>> On 25.01.17 at 16:44, wrote: >> > > ... so that they can be used by userspace x86

Re: [Xen-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

On Fri, Jan 27, 2017 at 12:13:58PM +0100, Juergen Gross wrote: > On 24/01/17 17:42, Roger Pau Monné wrote: > > Hello, > > > > The following commit: > > > > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894 > > Author: Juergen Gross > > Date: Tue Nov 22 07:10:58 2016 +0100 > >

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

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

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

flight 104984 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/104984/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10fail REGR. vs. 59254 test-amd64-i386-xl

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

On Mon, Jan 30, 2017 at 12:32:27PM +, Wei Liu wrote: > On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote: > > >>> On 25.01.17 at 16:44, wrote: > > > ... so that they can be used by userspace x86 instruction emulator test > > > program and fuzzer as well. > > >

Re: [Xen-devel] [PATCH 3/7] x86: extract macros to x86-defns.h

On Thu, Jan 26, 2017 at 03:55:27AM -0700, Jan Beulich wrote: > >>> On 25.01.17 at 16:44, wrote: > > ... so that they can be used by userspace x86 instruction emulator test > > program and fuzzer as well. > > Ah, here we go. This should be patch 2 then imo. > > > ---

Re: [Xen-devel] [PATCH 2/7] x86_emulate: lift a bunch of macros to header file

On Thu, Jan 26, 2017 at 03:51:35AM -0700, Jan Beulich wrote: > >>> On 25.01.17 at 16:44, wrote: > > Some of them can be shared between hypervisor and userspace fuzzing / > > test code. Instead of lifting the ones as we need, lift them all. > > While I appreciate the

  1   2   >