[Xen-devel] [ovmf bisection] complete build-i386

branch xen-unstable xenbranch xen-unstable job build-i386 testid xen-build Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced

[Xen-devel] [xen-4.7-testing baseline-only test] 71135: tolerable trouble: blocked/broken/fail/pass

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

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

flight 107025 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107025/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107011

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

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

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

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

Re: [Xen-devel] [For Xen-4.10 RFC PATCH 3/3] Prevent redundant icache flushes in populate_physmap()

On Fri, 31 Mar 2017, Wei Liu wrote: > On Fri, Mar 31, 2017 at 02:53:55PM +0100, Punit Agrawal wrote: > [...] > > > > Correct! > > > > invalidate_icache() flushes the entire instruction cache which ends up > > being called each time flush_page_to_ram() is invoked from > > alloc_heap_pages(). The

Re: [Xen-devel] [For Xen-4.10 RFC PATCH 2/3] arm: p2m: Prevent redundant icache flushes

On Fri, 31 Mar 2017, Punit Agrawal wrote: > When toolstack requests flushing the caches, flush_page_to_ram() is > called for each page of the requested domain. This needs to unnecessary > icache invalidation operations. > > Let's take the responsibility of performing icache operations and use >

Re: [Xen-devel] [For Xen-4.10 RFC PATCH 1/3] Allow control of icache invalidations when calling flush_page_to_ram()

On Fri, 31 Mar 2017, Punit Agrawal wrote: > flush_page_to_ram() unconditionally drops the icache. In certain > situations this leads to execessive icache flushes when > flush_page_to_ram() ends up being repeatedly called in a loop. > > Introduce a parameter to allow callers of flush_page_to_ram()

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

flight 107046 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107046/ 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 v3 07/26] ARM: GICv3 ITS: introduce host LPI array

On Fri, 31 Mar 2017, 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 not an option. > However Xen itself does not care about LPIs, as

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

On Fri, 31 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 device with the same identifier. > Allocate the

Re: [Xen-devel] [PATCH v3 05/26] ARM: GICv3 ITS: introduce ITS command handling

On Fri, 31 Mar 2017, Andre Przywara wrote: > 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

[Xen-devel] [xen-4.8-testing baseline-only test] 71134: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71134 xen-4.8-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71134/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9

Re: [Xen-devel] [PATCH v3 04/26] ARM: GICv3 ITS: map ITS command buffer

On Fri, 31 Mar 2017, 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 be able

Re: [Xen-devel] [PATCH v3 01/26] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

On Fri, 31 Mar 2017, Andre Przywara wrote: > 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. >

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

On Fri, 31 Mar 2017, 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 CPU. > This mapping is stored in the device and

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

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 LPIs are stored in tables in normal memory, which software has to > provide to the hardware. > Allocate the

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

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 by changing HCR_EL2 setting from a new presmp_initcall.

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

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 resulting in the > > wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their > > case init_traps will write the

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

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

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

On Fri, 31 Mar 2017, Julien Grall wrote: > Hi Stefano, > > On 30/03/17 00:47, Stefano Stabellini wrote: > > On Fri, 3 Mar 2017, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 01/03/17 22:15, Stefano Stabellini wrote: > > > > A potential race condition occurs when vgic_migrate_irq is called

[Xen-devel] [ovmf bisection] complete build-amd64-xsm

branch xen-unstable xenbranch xen-unstable job build-amd64-xsm testid xen-build Tree: ovmf https://github.com/tianocore/edk2.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and

[Xen-devel] [PATCH for 4.9 0/6] x86/emul: Fixes

This series started out as patchs 4 and 5, to aid the userspace fuzzing harness, but ended up discovering the bug in patch 3, which is security relevent. Patch 3 is a must-fix for Xen 4.9, before the bug needs an XSA. Patches 4-6 are nice-to-have. Andrew Cooper (6): x86/hvm: Correct some

[Xen-devel] [PATCH for 4.9 1/6] x86/hvm: Correct some address space terminology

The function hvm_translate_linear_addr() translates a virtual address to a linear address, not a linear address to a physical address. Correct its name. Both hvm_translate_virtual_addr() and hvmemul_virtual_to_linear() return a linear address, not a physical address. Correct the parameters

[Xen-devel] [PATCH for 4.9 2/6] x86/hvm: Correct long mode predicate

hvm_long_mode_enabled() tests for EFER.LMA, which is specifically different to EFER.LME. Rename it to match its behaviour, and have it strictly return a boolean value (although all its callers already use it in implicitly-boolean contexts, so no functional change). Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH for 4.9 5/6] x86/emul: Drop swint_emulate infrastructure

With the SVM injection logic capable of doing its own emulation, there is no need for this hardware-specific assistance in the common emulator. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Paul Durrant CC: Tim

[Xen-devel] [PATCH for 4.9 6/6] x86/emul: Require callers to provide LMA in the emulation context

Long mode (or not) influences emulation behaviour in a number of cases. Instead of reusing the ->read_msr() hook to obtain EFER.LMA, require callers to provide it directly. This simplifies all long mode checks during emulation to a simple boolean read, removing embedded msr reads. It also allows

[Xen-devel] [PATCH for 4.9 4/6] x86/svm: Introduce svm_emul_swint_injection()

Software events require emulation in some cases on AMD hardware. Introduce svm_emul_swint_injection() to perform this emulation if necessary in svm_inject_event(), which will cope with any sources of event, rather than just those coming from x86_emulate(). This logic mirrors inject_swint() in

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

c/s c785f759718 "x86/emul: Prepare to allow use of system segments for memory references" made alterations to hvm_virtual_to_linear_addr() to allow for the use of system segments. However, the determination of which segmentation mode to use was based on the current address size from emulation.

[Xen-devel] [PATCH v8 3/4] Introduce the Xen 9pfs transport header

Define the ring according to the protocol specification, using the new DEFINE_XEN_FLEX_RING_AND_INTF macro. Add the header to the C99 check. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: konrad.w...@oracle.com --- xen/include/Makefile | 4 +++-

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

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 get the declaration of memcpy and size_t. For the same reason, also add -include cstring to the C++ check when

[Xen-devel] [PATCH v8 4/4] Introduce the pvcalls header

Define the ring and request and response structs according to the specification. Use the new DEFINE_XEN_FLEX_RING macro. Add the header to the C99 check. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: konrad.w...@oracle.com --- xen/include/Makefile

[Xen-devel] [PATCH v8 0/4] new ring macros, 9pfs and pvcalls headers

Hi all, this patch series introduces a set of new ring macros to support rings in the formats specified by the Xen 9pfs transport and PV Calls protocol. It also introduces the Xen 9pfs and PV Calls protocols headers. Changes in v8: - code style fixes in Makefile - add back lost pvcall header

[Xen-devel] [PATCH v8 1/4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

This patch introduces macros, structs and functions to handle rings in the format described by docs/misc/pvcalls.markdown and docs/misc/9pfs.markdown. The index page (struct __name##_data_intf) contains the indexes and the grant refs to setup two rings. Indexes page

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

On Fri, 31 Mar 2017, Jan Beulich wrote: > >>> On 30.03.17 at 23:04, wrote: > > --- a/.gitignore > > +++ b/.gitignore > > @@ -274,6 +274,7 @@ xen/arch/*/efi/compat.c > > xen/arch/*/efi/efi.h > > xen/arch/*/efi/runtime.c > > xen/include/headers.chk > >

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

On Fri, 31 Mar 2017, Julien Grall wrote: > Hi Stefano, > > On 03/31/2017 07:01 PM, Stefano Stabellini wrote: > > On Fri, 31 Mar 2017, Julien Grall wrote: > > > On 30/03/17 20:54, Julien Grall wrote: > > > > On 30/03/2017 19:55, Stefano Stabellini wrote: > > > > > On Thu, 30 Mar 2017, Julien Grall

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

Hi Stefano, On 03/31/2017 07:01 PM, Stefano Stabellini wrote: On Fri, 31 Mar 2017, Julien Grall wrote: On 30/03/17 20:54, Julien Grall wrote: On 30/03/2017 19:55, Stefano Stabellini wrote: On Thu, 30 Mar 2017, Julien Grall wrote: On 30/03/17 19:37, Stefano Stabellini wrote: On Thu, 30 Mar

Re: [Xen-devel] [PATCH v3 15/19] xen/arm: Introduce a helper to check local abort is enabled

On Fri, 31 Mar 2017, Wei Chen wrote: > In previous patch, we have umasked the Abort/SError bit for Xen > in most of its running time. So in some use-cases, we have to > check whether the abort is enabled in current context. For example, > while we want to synchronize SErrors, we have to confirm

Re: [Xen-devel] [PATCH v3 18/19] xen/arm: Prevent slipping hypervisor SError to guest

Hi Stefano, On 03/31/2017 07:42 PM, Stefano Stabellini wrote: On Fri, 31 Mar 2017, Julien Grall wrote: Hi Wei, On 31/03/17 14:07, Wei Chen wrote: If there is a pending SError while we're returning from trap. If the SError handle option is "DIVERSE", we have to prevent slipping this

Re: [Xen-devel] [PATCH v3 18/19] xen/arm: Prevent slipping hypervisor SError to guest

On Fri, 31 Mar 2017, Julien Grall wrote: > Hi Wei, > > On 31/03/17 14:07, Wei Chen wrote: > > If there is a pending SError while we're returning from trap. If the > > SError handle option is "DIVERSE", we have to prevent slipping this > > hypervisor SError to guest. So we have to use the dsb/isb

Re: [Xen-devel] [PATCH v3 17/19] xen/arm: Isolate the SError between the context switch of 2 vCPUs

On Fri, 31 Mar 2017, Julien Grall wrote: > Hi Wei, > > On 31/03/17 14:07, Wei Chen wrote: > > If there is a pending SError while we are doing context switch, if the > > SError handle option is "FORWARD", We have to guranatee this serror to > > NIT: s/guranatee/guarantee/ > > s/serror/Serror/ >

Re: [Xen-devel] [PATCH v3 16/19] xen/arm: Introduce a macro to synchronize SError

On Fri, 31 Mar 2017, Wei Chen wrote: > In previous patches, we have provided the ability to synchronize > SErrors in exception entries. But we haven't synchronized SErrors > while returning to guest and doing context switch. > > So we still have two risks: > 1. Slipping hypervisor SErrors to

Re: [Xen-devel] [PATCH v3 02/19] xen/arm: Introduce a helper to get default HCR_EL2 flags

On Fri, 31 Mar 2017, Wei Chen wrote: > We want to add HCR_EL2 register to Xen context switch. And each copy > of HCR_EL2 in vcpu structure will be initialized with the same set > of trap flags as the HCR_EL2 register. We introduce a helper here to > represent these flags to be reused easily. > >

Re: [Xen-devel] [PATCH v3 03/19] xen/arm: Set and restore HCR_EL2 register for each vCPU separately

On Fri, 31 Mar 2017, Wei Chen wrote: > Different domains may have different HCR_EL2 flags. For example, the > 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So > we give each domain a default HCR_EL2 value and save it in the vCPU's > context. > > HCR_EL2 register has only one

Re: [Xen-devel] [PATCH v3 01/19] xen/arm: Save ESR_EL2 to avoid using mismatched value in syndrome check

On Fri, 31 Mar 2017, Wei Chen wrote: > Xen will do exception syndrome check while some types of exception > take place in EL2. The syndrome check code read the ESR_EL2 register > directly, but in some situation this register maybe overridden by > nested exception. > > For example, if we re-enable

[Xen-devel] [xen-4.7-testing test] 107021: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v3] xen/arm: alternative: Register re-mapped Xen area as a temporary virtual region

On Fri, 31 Mar 2017, Jan Beulich wrote: > >>> On 29.03.17 at 16:23, wrote: > > On 27/03/17 09:40, Wei Chen wrote: > >> @@ -154,8 +155,12 @@ static int __apply_alternatives_multi_stop(void > >> *unused) > >> int ret; > >> struct alt_region region; > >>

[Xen-devel] [PATCH v3 21/26] 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 v3 23/26] 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 v3 20/26] 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 v3 13/26] 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 v3 22/26] 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 v3 19/26] 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 v3 25/26] 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 v3 26/26] 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 v3 08/26] 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 v3 16/26] 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 v3 02/26] 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 v3 24/26] 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 v3 14/26] 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 v3 18/26] 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 v3 15/26] 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 | 31 +--

[Xen-devel] [PATCH v3 03/26] 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 v3 09/26] 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 v3 06/26] 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 v3 17/26] 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 v3 12/26] 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 v3 11/26] 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 v3 07/26] 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 v3 01/26] 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 v3 00/26] arm64: Dom0 ITS emulation

Hi, another desperate try to get the ITS Dom0 emulation series ready. Major changes this time: - Instead of allocating struct pending_irq's on the fly during LPI injection, we allocate them upon mapping a device and assign them upon the LPI mapping into a radix tree, so that we can quickly

[Xen-devel] [PATCH v3 10/26] 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 v3 05/26] 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 v3 04/26] 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

Re: [Xen-devel] [PATCH for-4.9] xen/arm: acpi: Map MMIO on fault in stage-2 page table for the hardware domain

On Fri, 31 Mar 2017, Julien Grall wrote: > On 30/03/17 20:54, Julien Grall wrote: > > On 30/03/2017 19:55, Stefano Stabellini wrote: > > > On Thu, 30 Mar 2017, Julien Grall wrote: > > > > On 30/03/17 19:37, Stefano Stabellini wrote: > > > > > On Thu, 30 Mar 2017, Julien Grall wrote: > > > Fair

Re: [Xen-devel] arm64: dma_to_phys/phys_to_dma need to be properly implemented

Ok, no worries On Fri, 31 Mar 2017, Oleksandr Andrushchenko wrote: > Hi, Stefano > > Unfortunately I had to switch to other tasks, > > but I'll get back to this issue asap > > Thank you > > > On 03/30/2017 01:36 AM, Stefano Stabellini wrote: > > On Wed, 29 Mar 2017, Oleksandr Andrushchenko

[Xen-devel] [xen-4.6-testing test] 107020: regressions - trouble: broken/fail/pass

flight 107020 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/107020/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumprun-i386 12 guest-destroyfail REGR. vs. 106819

Re: [Xen-devel] Question about the general performance counter overflow interrupt handling

On 03/31/2017 01:32 PM, Meng Xu wrote: > Hi Boris, > > On Fri, Mar 31, 2017 at 12:01 PM, Boris Ostrovsky > wrote: When I program the general performance counter to trigger an overflow interrupt, I set the following bits for the event selector register

Re: [Xen-devel] Question about the general performance counter overflow interrupt handling

Hi Boris, On Fri, Mar 31, 2017 at 12:01 PM, Boris Ostrovsky wrote: > >>> When I program the general performance counter to trigger an overflow >>> interrupt, I set the following bits for the event selector register >>> and run a task to generate the L3 cache cache

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

This run is configured for baseline tests only. flight 71133 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71133/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 3

Re: [Xen-devel] Xen Security Advisory 206 - xenstore denial of service via repeated update

(dropping some of the lists) Michael Young writes ("Re: [Xen-devel] Xen Security Advisory 206 - xenstore denial of service via repeated update"): > On Wed, 29 Mar 2017, Xen.org security team wrote: > >Xen Security Advisory XSA-206 > > version 9 >

[Xen-devel] [ovmf test] 107027: regressions - FAIL

flight 107027 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/107027/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 107018 build-i386

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

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

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

flight 107033 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107033/ 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 v5 3/3] xen/arm: vgic_migrate_irq: do not race against GIC_IRQ_GUEST_MIGRATING

Hi Stefano, On 30/03/17 00:47, Stefano Stabellini wrote: On Fri, 3 Mar 2017, Julien Grall wrote: Hi Stefano, On 01/03/17 22:15, Stefano Stabellini wrote: A potential race condition occurs when vgic_migrate_irq is called a second time, while GIC_IRQ_GUEST_MIGRATING is already set. In that

Re: [Xen-devel] Question about the general performance counter overflow interrupt handling

>> When I program the general performance counter to trigger an overflow >> interrupt, I set the following bits for the event selector register >> and run a task to generate the L3 cache cache miss. >> FLAG_ENABLE: 0x40UL >> FLAG_INT:0x10UL >> FLAG_USR: 0x01UL >> L3_ALLMISS_EVENT

Re: [Xen-devel] Question about the general performance counter overflow interrupt handling

>>> On 31.03.17 at 17:41, wrote: > I'm wondering: > How does Xen (vpmu) handle the general performance counter's overflow > interrupt? > Could you point me to the function handler, if Xen does handle it? Two simple steps take you there: grep for LVTPC to find which vector

Re: [Xen-devel] [PATCH v3 6/8] x86/vioapic: introduce support for multiple vIO APICS

>>> On 29.03.17 at 16:47, wrote: > +static unsigned int base_gsi(const struct domain *d, > + const struct hvm_vioapic *vioapic) > +{ > +const struct hvm_vioapic *tmp; > +unsigned int base_gsi = 0, nr_vioapics =

Re: [Xen-devel] Question about the general performance counter overflow interrupt handling

[Sorry, I cc.ed Quan's previous email at Intel. Change to his current email.] On Fri, Mar 31, 2017 at 11:41 AM, Meng Xu wrote: > Hi Jan and Boris, > > I'm Meng Xu from the University of Pennsylvania. > > I'm wondering: > How does Xen (vpmu) handle the general performance

[Xen-devel] [PATCH v3] ns16550-Add-command-line-parsing-adjustments

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

[Xen-devel] Question about the general performance counter overflow interrupt handling

Hi Jan and Boris, I'm Meng Xu from the University of Pennsylvania. I'm wondering: How does Xen (vpmu) handle the general performance counter's overflow interrupt? Could you point me to the function handler, if Xen does handle it? ---What I want to achieve--- I'm looking at the real-time

Re: [Xen-devel] [PATCH v2] xen: make functions in xen-acpi-processor return void

On 31/03/17 17:15, Konrad Rzeszutek Wilk wrote: > On Fri, Mar 31, 2017 at 04:40:56PM +0200, Juergen Gross wrote: >> There are several functions in xen-acpi-processor which either always >> return the same value or where the returned value is never checked. >> >> Make the functions return void. >

Re: [Xen-devel] [PATCH v5 2/3] xen/arm: move setting of new target vcpu to vgic_migrate_irq

Hi Stefano, On 30/03/17 00:48, Stefano Stabellini wrote: On Fri, 3 Mar 2017, Julien Grall wrote: Hi Stefano, On 01/03/17 22:15, Stefano Stabellini wrote: Move the atomic write of rank->vcpu, which sets the new vcpu target, to vgic_migrate_irq, at the beginning of the lock protected area

Re: [Xen-devel] [PATCH v2] xen: make functions in xen-acpi-processor return void

On 31/03/17 17:13, Boris Ostrovsky wrote: > On 03/31/2017 10:40 AM, Juergen Gross wrote: >> There are several functions in xen-acpi-processor which either always >> return the same value or where the returned value is never checked. >> >> Make the functions return void. >> >> Signed-off-by:

Re: [Xen-devel] [PATCH v3 5/8] x86/vioapic: allow the vIO APIC to have a variable number of pins

>>> On 29.03.17 at 16:47, wrote: > Although it's still always set to VIOAPIC_NUM_PINS (48). > > Add a new field to the hvm_ioapic struct to contain the number of pins (number > of IO redirection table entries) and turn the redirection table into a > variable > sized array.

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

On 03/31/2017 10:46 AM, Mohit Gambhir 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 MSRs since > hyperthreading is not exposed to guests

Re: [Xen-devel] [PATCH v3 4/8] x86/hvm: convert gsi_assert_count into a variable size array

>>> On 29.03.17 at 16:47, wrote: > Rearrange the fields of hvm_irq so that gsi_assert_count can be converted into > a variable size array and add a new field to account the number of GSIs. > > Due to this changes the irq member in the hvm_domain struct also needs to >

Re: [Xen-devel] [PATCH v2] xen: make functions in xen-acpi-processor return void

On Fri, Mar 31, 2017 at 04:40:56PM +0200, Juergen Gross wrote: > There are several functions in xen-acpi-processor which either always > return the same value or where the returned value is never checked. > > Make the functions return void. Well, we could actually check it and do some extra

Re: [Xen-devel] [PATCH v2] xen: make functions in xen-acpi-processor return void

On 03/31/2017 10:40 AM, Juergen Gross wrote: > There are several functions in xen-acpi-processor which either always > return the same value or where the returned value is never checked. > > Make the functions return void. > > Signed-off-by: Juergen Gross > --- >

Re: [Xen-devel] [PATCH] xl: Add 'pvh' config option

On 03/31/2017 10:33 AM, Ian Jackson wrote: > Roger Pau Monné writes ("Re: [PATCH] xl: Add 'pvh' config option"): >> On Fri, Mar 31, 2017 at 09:59:09AM -0400, Boris Ostrovsky wrote: >>> That would make the toolstack have three guest types while the >>> hypervisor has two. > Is that a problem,

  1   2   3   >