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 the
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
R
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
This series started out as patches 4 and 5, to aid the userspace fuzzing
harness, but ended up discovering the bug in patch 3, which is security
relevant.
Patch 3 is a must-fix for Xen 4.9, before the bug needs an XSA. Patches 4-6
are nice-to-have.
The main change from v1 is reworking of patch 3
On 4/6/2017 1:18 AM, Yu Zhang wrote:
On 4/6/2017 1:01 AM, George Dunlap wrote:
On 05/04/17 17:32, Yu Zhang wrote:
On 4/6/2017 12:35 AM, George Dunlap wrote:
On 05/04/17 17:22, Yu Zhang wrote:
On 4/5/2017 10:41 PM, George Dunlap wrote:
On Sun, Apr 2, 2017 at 1:24 PM, Yu Zhang
wrote:
A
On Wed, Apr 5, 2017 at 9:04 AM, George Dunlap wrote:
> On Tue, Apr 4, 2017 at 4:24 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 poses
>> a problem for us
The fuzzing harness conditionally disables hooks to test error paths in the
emulator. However, fuzz_emulops is a static structure.
c/s 69f4633 "tools/insn-fuzz: Support AFL's afl-clang-fast mode" introduced
persistent mode, but because fuzz_emulops is static, the clobbering of hooks
accumulates o
For control-flow changes, the emulator needs to perform a zero-length
instruction fetch at the target offset. It also passes NULL for the
destination buffer, as there is no instruction stream to collect.
This trips up UBSAN when passed to memcpy(), as passing NULL is undefined
behaviour per the C
AFL has a measure of stability, where it passes the same corpus into the
fuzzing harness and observes whether the execution path changes from before.
Any instability in the fuzzing harness reduces its effectiveness, as an
observed crash may not reliably be caused by the original corpus.
In prepara
The correct prototypes for the hooks are to use enum x86_segment rather than
unsigned int. It is implementation specific as to whether this compiles.
assert() that the emulator never passes an inappropriate segment. The only
hook which may legitimately be passed x86_seg_none is invlpg().
Signed
c/s 92cf67888 "x86/emul: Hold x86_emulate() to strict X86EMUL_EXCEPTION
requirements" was appropriate for the hypervisor, but the fuzzer stubs didn't
conform to the stricter requirements. AFL is very quick to discover this.
Extend the fuzzing harness exception logic to raise exceptions appropriat
x86_emulates()'s is_branch_step() performs a speculative read of
IA32_DEBUGCTL, but doesn't squash exceptions should they arise. In reality,
this MSR is always available.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: George Dunlap
CC: Ian Jackson
CC: Wei Liu
---
tools/fuzz/x
Requested-by: Jan Beulich
Signed-off-by: Andrew Cooper
--
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c38bc
This is a subset of the previous fuzzing bugfix/improvement series, which is
the minimum required to avoid hitting assertions in the emulator.
From a 4.9 point of view, this entirely userspace testing harness changes (so
safe to take), but it allows us to sensibly fuzz the emulator in the
hypervis
flight 107205 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107205/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 107183
pass in 107205
test-amd64-amd6
On 4/6/2017 1:28 AM, Yu Zhang wrote:
On 4/6/2017 1:18 AM, Yu Zhang wrote:
On 4/6/2017 1:01 AM, George Dunlap wrote:
On 05/04/17 17:32, Yu Zhang wrote:
On 4/6/2017 12:35 AM, George Dunlap wrote:
On 05/04/17 17:22, Yu Zhang wrote:
On 4/5/2017 10:41 PM, George Dunlap wrote:
On Sun, Apr 2
When rebooting DOM0 with ACPI, the kernel is crashing with the stack trace [1].
This is happening because when EFI runtimes are enabled, the reset code
(see machin_restart) will first try to use EFI restart method.
However, the EFI restart code is expecting the reset_system callback to
be always
On 4/6/2017 2:02 AM, Yu Zhang wrote:
On 4/6/2017 1:28 AM, Yu Zhang wrote:
On 4/6/2017 1:18 AM, Yu Zhang wrote:
On 4/6/2017 1:01 AM, George Dunlap wrote:
On 05/04/17 17:32, Yu Zhang wrote:
On 4/6/2017 12:35 AM, George Dunlap wrote:
On 05/04/17 17:22, Yu Zhang wrote:
On 4/5/2017 10:4
On Wed, 5 Apr 2017, Julien Grall wrote:
> (CC Lars)
>
> Hi,
>
> On 05/04/17 12:51, Wei Liu wrote:
> > On Wed, Apr 05, 2017 at 05:04:00PM +0530, Tejaswini Poluri wrote:
> > > Hi Stefano and Julien,
> > >
> > > This is Tejaswini. I had been working as a Senior Software developer in
> > > Samsung a
On 05/04/17 16:03, Wei Liu wrote:
On Wed, Apr 05, 2017 at 03:58:05PM +0100, Julien Grall wrote:
Hi Razvan,
On 05/04/17 15:53, Razvan Cojocaru wrote:
Currently xc_translate_foreign_address() only checks for the PSE bit on
level 2 entries (that's 2 MB pages on x64 and 32-bit with PAE, and 4 MB
On 04/05/2017 01:33 PM, Andrew Cooper wrote:
> 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 n
On 04/05/2017 01:33 PM, Andrew Cooper wrote:
> 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
On 05/04/17 19:58, Boris Ostrovsky wrote:
> On 04/05/2017 01:33 PM, Andrew Cooper wrote:
>> 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
Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org
---
NB: The new macros have been committed
Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
register as a xenbus driver and add struct p9_trans_module to register
as v9fs driver.
All functions are empty stubs for now.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
CC: gr...
This patch adds a Kconfig option and Makefile support for building the
9pfs Xen driver.
Signed-off-by: Stefano Stabellini
Reviewed-by: Juergen Gross
CC: gr...@kaod.org
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Eric Van Hensbergen
CC: Ron Minnich
CC: Latchesar Ionkov
CC: v9fs-deve
It uses the new ring.h macros to declare rings and interfaces.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org
---
include/xen/interface/io/9pfs.h | 36
1 file changed, 36 inse
Implement struct p9_trans_module create and close functions by looking
at the available Xen 9pfs frontend-backend connections. We don't expect
many frontend-backend connections, thus walking a list is OK.
Send requests to the backend by copying each request to one of the
available rings (each fron
Hi all,
This patch series implements a new transport for 9pfs, aimed at Xen
systems.
The transport is based on a traditional Xen frontend and backend drivers
pair. This patch series implements the frontend, which typically runs in
a regular unprivileged guest.
I also sent a series that implement
Implement functions to handle the xenbus handshake. Upon connection,
allocate the rings according to the protocol specification.
Initialize a work_struct and a wait_queue. The work_struct will be used
to schedule work upon receiving an event channel notification from the
backend. The wait_queue wi
Upon receiving a notification from the backend, schedule the
p9_xen_response work_struct. p9_xen_response checks if any responses are
available, if so, it reads them one by one, calling p9_client_cb to send
them up to the 9p layer (p9_client_cb completes the request). Handle the
ring following the
Thank you Wei. I committed this series. I fixed on commit patch #16 that
has 2 asserts.
On Wed, 5 Apr 2017, Wei Chen wrote:
> From XSA-201, we know that, a guest could trigger SErrors when accessing
> memory mapped HW in a non-conventional way. In the patches for XSA-201,
> we crash the guest when
flight 107207 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107207/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 106829
Regressions which are r
We now have macros in place to make it less verbose to add a scalar
to QDict and QList, so use them. To make this patch smaller to
review, a couple of subdirectories were done in earlier patches.
Patch created mechanically via:
spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-fil
On 04/05/2017 02:14 PM, Julien Grall wrote:
> When rebooting DOM0 with ACPI, the kernel is crashing with the stack trace
> [1].
>
> This is happening because when EFI runtimes are enabled, the reset code
> (see machin_restart) will first try to use EFI restart method.
>
> However, the EFI restart
The patch introduces a macro FIXED_CTR_CTRL_ANYTHREAD_MASK and uses it
to mask .Anythread bit for all counter in IA32_FIXED_CTR_CTRL MSR in all
versions of Intel Arhcitectural Performance Monitoring. Masking .AnyThread bit
is necesssry for two reasons:
1. We need to be consistent in the implemen
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
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 vgic_vcpu_inje
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 p->inflight,
On Wed, 5 Apr 2017, Julien Grall wrote:
> When rebooting DOM0 with ACPI, the kernel is crashing with the stack trace
> [1].
>
> This is happening because when EFI runtimes are enabled, the reset code
> (see machin_restart) will first try to use EFI restart method.
>
> However, the EFI restart co
This run is configured for baseline tests only.
flight 71151 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71151/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 win
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/arch/arm/gic-v3-its.c
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 Przywara
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.
This introduces a function to re
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
iterate over all mapped LPIs and filter for those from that particular
VCPU.
Signed-off-by: A
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 a/xen/arch/arm/vgic-v3-its.c b/xen
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.
This removes a "TBD" comment, as we now populate the processor nu
To safely handle 64-bit registers even on 32-bit systems, introduce
a BIT_ULL variant (lifted from Linux).
Signed-off-by: Andre Przywara
---
xen/include/asm-arm/bitops.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
index bda8898.
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 d
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/arch/arm/vgic-v3-its.c| 416 ++
xen/arch/arm/vg
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
r
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
---
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 n
Parse the GIC subnodes in the device tree 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 (as an EXPERT option), use
XEN_CONFIG_EX
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. We do this
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 LPI on the host can be quickly forwarded to a guest.
Beside entering the VCPU and the virtual LPI
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 | 41 +
1 file changed
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 fo
To safely handle 64-bit registers even on 32-bit systems, introduce
a GENMASK_ULL variant (lifted from Linux).
This adds a BITS_PER_LONG_LONG define as well.
Also fix a bug in the comment for the existing GENMASK variant.
Signed-off-by: Andre Przywara
---
xen/include/asm-arm/config.h | 2 ++
xen
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 corresponding host MAPD
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, sin
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.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c| 33 ++
xen/arch/ar
Hi,
another round with lots of fixes for the ITS emulation series.
The access to guest memory has been reworked, we now use a routine to
copy to and from guest memory to also guarantee atomic access.
This is courtesy of Vijaya Kumar, from a previous series.
For a detailed changelog see below.
Ope
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/arch/arm/gic-v3-its.c | 4
xen/a
Upon receiving an LPI on the host, 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.
Als
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 the
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 | 32
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
late
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/arch/arm/vgic-v3-i
For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
This introduces a function to initialize a virtual ITS.
We maintain a list of virtual ITSes, at the moment for the only
purpose of later being able to free them ag
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 fo
Create a new file to hold the emulation code for the ITS widget.
This just holds the data structure and a init and free function for now.
Signed-off-by: Andre Przywara
---
xen/arch/arm/Makefile| 1 +
xen/arch/arm/vgic-v3-its.c | 85
xen
On 04/04/17 17:51, Julien Grall wrote:
> Hi Andre,
>
> On 03/04/17 21:28, Andre Przywara wrote:
>> 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 e
On Thu, 6 Apr 2017, Andre Przywara wrote:
> Parse the GIC subnodes in the device tree 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 Kconf
On Thu, 6 Apr 2017, Andre Przywara wrote:
> To safely handle 64-bit registers even on 32-bit systems, introduce
> a BIT_ULL variant (lifted from Linux).
>
> Signed-off-by: Andre Przywara
Reviewed-by: Stefano Stabellini
> ---
> xen/include/asm-arm/bitops.h | 1 +
> 1 file changed, 1 insertion(
On Thu, 6 Apr 2017, Andre Przywara wrote:
> To safely handle 64-bit registers even on 32-bit systems, introduce
> a GENMASK_ULL variant (lifted from Linux).
> This adds a BITS_PER_LONG_LONG define as well.
> Also fix a bug in the comment for the existing GENMASK variant.
>
> Signed-off-by: Andre P
On Thu, 6 Apr 2017, 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.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Stefano Stabellini
On Thu, 6 Apr 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 requi
On Thu, 6 Apr 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 c
On Thu, 6 Apr 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 e
On Thu, 6 Apr 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 respective
On Thu, 6 Apr 2017, Andre Przywara wrote:
> Upon receiving an LPI on the host, 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 l
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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
flight 107206 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107206/
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
test-armhf-armhf-xl
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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/arch/arm/vgic-v3-its.c| 416
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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.
>
> Sign
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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
> m
On Thu, 6 Apr 2017, 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 that
> any triggering LPI on the host can be quickly forwarded to a g
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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-o
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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
> ---
> xe
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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 o
On Thu, 6 Apr 2017, Andre Przywara wrote:
> 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.
> This remove
flight 107208 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107208/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-amd64 3 host-install(3) broken in 107186 pass in
107208
test-xtf-amd64-amd64-5 20
flight 107209 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107209/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pair 3 host-install/src_host(3) broken in 107185 pass in
107209
test-armhf-armhf-xl-credit
This run is configured for baseline tests only.
flight 71152 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71152/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-xtf-amd64-amd64-2 20 xtf/test-hvm32-invlpg~sha
Hi!
I'd love to work on the Code Review Dashboard project for this round of
Outreachy.
Are the steps outlined here http://markmail.org/message/7adkmords3imkswd
still the first
contribution you'd like to see?
So is this a project that has been worked on in previous rounds of
GSOC/Outreachy also?
On 03/31/17 01:24 -0600, Jan Beulich wrote:
> >>> On 31.03.17 at 04:34, wrote:
> > On 03/30/17 08:35 -0600, Jan Beulich wrote:
> >> >>> On 30.03.17 at 08:19, wrote:
> >> > --- a/xen/arch/x86/cpu/mcheck/mce.c
> >> > +++ b/xen/arch/x86/cpu/mcheck/mce.c
> >> > @@ -42,6 +42,13 @@ DEFINE_PER_CPU_READ_
Thanks to you and Julien :)
On 2017/4/6 3:18, Stefano Stabellini wrote:
> Thank you Wei. I committed this series. I fixed on commit patch #16 that
> has 2 asserts.
>
> On Wed, 5 Apr 2017, Wei Chen wrote:
>> From XSA-201, we know that, a guest could trigger SErrors when accessing
>> memory mapped
1. Distinguish 'severity_cpu' used in mcheck_cmn_handler() and
mce_softirq(), which should be different variables. Otherwise, they
may interfere with each other if MC# comes during mce_softirq().
2. Always (re-)initialize 'severity_cpu' to clear historical information.
Signed-off-by: Haozhon
201 - 300 of 308 matches
Mail list logo
