[Xen-devel] [RFC PATCH 17/24] ARM: vITS: handle MAPTI command

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU pair and actually instantiates LPI interrupts. We allocate a new host LPI and connect that one 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] [RFC PATCH 18/24] 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] [RFC PATCH 16/24] 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] [RFC PATCH 23/24] 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] [RFC PATCH 19/24] 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/gic-its.c| 21

[Xen-devel] [RFC PATCH 03/24] 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] [RFC PATCH 24/24] 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] [RFC PATCH 09/24] 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] [RFC PATCH 21/24] 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). To avoid iterating (and mapping!) all guest tables, we instead go through the host LPI table to find any LPIs targetting this VCPU. We then update the

[Xen-devel] [RFC PATCH 07/24] 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 a list to later

[Xen-devel] [RFC PATCH 14/24] 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-its.c | 34 ++ 1 file changed, 34 insertions(+) diff --git

[Xen-devel] [RFC PATCH 08/24] 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] [RFC PATCH 00/24] [FOR 4.9] arm64: Dom0 ITS emulation

Hi, apologies for sending this series, which due to its early status is now targeting Xen 4.9, still before the 4.8 hard feature freeze, but there seems to be some interested parties and I wanted to get the discussion started on this. This series introduces ARM GICv3 ITS emulation, for now

[Xen-devel] [RFC PATCH 06/24] 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] [RFC PATCH 11/24] 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] [RFC PATCH 22/24] 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-its.c | 22 ++ xen/arch/arm/vgic-v3.c| 12

[Xen-devel] [RFC PATCH 02/24] ARM: GICv3: allocate LPI pending and property table

The ARM GICv3 ITS 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

[Xen-devel] [RFC PATCH 12/24] 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] [RFC PATCH 05/24] 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] [RFC PATCH 01/24] 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] [RFC PATCH 15/24] 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-its.c | 30 ++ 1

Re: [Xen-devel] [Outreachy]Code Standards Checking using clang-format

The idea is a nice one, well this would help me to get familiar with the skills needed for the current project On Tue, Sep 27, 2016 at 8:45 PM, Wei Liu wrote: > On Tue, Sep 27, 2016 at 09:22:37AM -0500, Doug Goldstein wrote: > > On 9/26/16 3:53 PM, nimisha agarwal wrote: >

[Xen-devel] [RFC PATCH 10/24] 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] [RFC PATCH 20/24] 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

[Xen-devel] [RFC PATCH 04/24] 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

Re: [Xen-devel] [PULL 0/1] tags/xen-20160927-tag

On 27 September 2016 at 18:36, Stefano Stabellini wrote: > The following changes since commit 25930ed60aad49f1fdd7de05272317c86ce1275b: > > Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into > staging (2016-09-27 23:10:12 +0100) > > are available

Re: [Xen-devel] [PATCH v2 03/16] x86emul: track only rIP in emulator state

On 28/09/16 09:08, Jan Beulich wrote: > Now that all decoding happens in x86_decode() there's no need to keep > the local registers copy in struct x86_emulate_state. Only rIP gets > updated in the decode phase, so only that register needs tracking > there. All other (read-only) registers can be

Re: [Xen-devel] [PATCH v3 2/3] xen/pciback: avoid multiple entries in slot list

On 23/09/16 12:15, David Vrabel wrote: > On 22/09/16 22:02, Boris Ostrovsky wrote: >> On 09/22/2016 04:45 AM, Juergen Gross wrote: >>> The Xen pciback driver has a list of all pci devices it is ready to >>> seize. There is no check whether a to be added entry already exists. >>> While this might

Re: [Xen-devel] [PATCH v2 04/16] x86emul: complete decoding of two-byte instructions

On 28/09/16 09:08, Jan Beulich wrote: > @@ -1651,6 +1668,34 @@ x86_decode_onebyte( > } > > static int > +x86_decode_twobyte( > +struct x86_emulate_state *state, > +struct x86_emulate_ctxt *ctxt, > +const struct x86_emulate_ops *ops) > +{ > +int rc = X86EMUL_OKAY; > + > +

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

flight 101186 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/101186/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101177

Re: [Xen-devel] [PATCH v6 16/16] libxl/arm: Add the size of ACPI tables to maxmem

Hi, On 28/09/2016 06:17, Wei Liu wrote: On Wed, Sep 28, 2016 at 06:11:53AM -0700, Shannon Zhao wrote: libxl__get_acpi_size(gc, info, gic_version /* not build_state anymore */) /* also fix up libxl__estimate_madt_size */ /* this is the function called when constructing the domain etc,

Re: [Xen-devel] [PATCH v2 01/16] x86emul: split instruction decoding from execution

On 28/09/16 09:06, Jan Beulich wrote: > This is only the mechanical part, a subsequent patch will make non- > mechanical adjustments to actually do all decoding in this new > function. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH Altp2m cleanup v7] Cleaning up altp2m code

Altp2m cleanup work The altp2m clean work is motivated by the following URLs: https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html Most of the work has been: Lots of white space, indentation, and other coding style preference corrections. Lots of function return type

Re: [Xen-devel] [PATCH v2 02/16] x86emul: fetch all insn bytes during the decode phase

On 28/09/16 09:07, Jan Beulich wrote: > This way we can offer to callers the service of just sizing > instructions, and we also can better guarantee not to raise the wrong > fault due to not having read all relevant bytes. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew

[Xen-devel] [xen-unstable-smoke test] 101191: regressions - FAIL

flight 101191 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101191/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 101184 Tests which

[Xen-devel] [PATCH Altp2m cleanup v7] altp2m cleanup work.

Indent goto labels by one space. Inline (header) altp2m functions. In do_altp2m_op(), during the sanity check of the passed command, return -EOPNOTSUPP if not a valid command. In do_altp2m_op(), when evaluating a command, ASSERT_UNREACHABLE() if the command is not recognizable. The sanity check

Re: [Xen-devel] [Qemu-devel] [PATCH] xenpv: Fix qemu_uuid compiling error

On Tue, 27 Sep 2016, Eric Blake wrote: > On 09/27/2016 04:20 AM, Fam Zheng wrote: > > 9c5ce8db2 switched the type of qemu_uuid and this should have followed. > > Fix it. > > > > Signed-off-by: Fam Zheng > > --- > > hw/xenpv/xen_domainbuild.c | 2 +- > > 1 file changed, 1

[Xen-devel] [PATCH v8 04/16] libxl/arm: Estimate the size of ACPI tables

Estimate the size of ACPI tables and reserve a memory map space for ACPI tables. Signed-off-by: Shannon Zhao --- tools/libxl/libxl_arm_acpi.c | 95 xen/include/acpi/actbl1.h| 2 + 2 files changed, 97 insertions(+) diff

[Xen-devel] [PATCH v8 05/16] libxl/arm: Construct ACPI RSDP table

Construct ACPI RSDP table and add a helper to calculate the ACPI table checksum. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- tools/libxl/libxl_arm_acpi.c | 39

[Xen-devel] [PATCH v8 03/16] libxl/arm: Generate static ACPI DSDT table

It uses static DSDT table like the way x86 uses. Currently the DSDT table only contains processor device objects and it generates the maximal objects which so far is 128. While the GUEST_MAX_VCPUS is defined under __XEN__ or __XEN_TOOLS__, it needs to add -D__XEN_TOOLS__ to compile mk_dsdt.c.

[Xen-devel] [PATCH v8 12/16] libxl/arm: Factor finalise_one_memory_node as a gerneric function

Rename finalise_one_memory_node to finalise_one_node and pass the node name via function parameter. This is useful for adding ACPI module which will be added by a later patch. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu

[Xen-devel] [PATCH v8 01/16] tools/libxl: Add an unified configuration option for ACPI

Since the existing configuration option "u.hvm.acpi" is x86 specific and we want to reuse it on ARM as well, add a unified option "acpi" for x86 and ARM, and for ARM it's disabled by default. Signed-off-by: Shannon Zhao Acked-by: Wei Liu ---

[Xen-devel] [PATCH v8 11/16] libxl/arm: Construct ACPI DSDT table

Copy the static DSDT table into ACPI blob. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- tools/libxl/libxl_arm_acpi.c | 10 ++ 1 file changed, 10 insertions(+) diff --git

[Xen-devel] [PATCH v8 07/16] libxl/arm: Construct ACPI GTDT table

Construct GTDT table with the interrupt information of timers. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- tools/libxl/libxl_arm_acpi.c | 38 ++ 1 file changed,

[Xen-devel] [PATCH v8 00/16] Xen ARM DomU ACPI support

The design of this feature is described as below. Firstly, the toolstack (libxl) generates the ACPI tables according the number of vcpus and gic controller. Then, it copies these ACPI tables to DomU non-RAM memory map space and passes them to UEFI firmware through the "ARM multiboot" protocol.

[Xen-devel] [PATCH v8 09/16] libxl/arm: Construct ACPI MADT table

According to the GIC version, construct the MADT table. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- tools/libxl/libxl_arm_acpi.c | 84 1 file changed,

[Xen-devel] [PATCH v8 06/16] libxl/arm: Construct ACPI XSDT table

Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- tools/libxl/libxl_arm_acpi.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/tools/libxl/libxl_arm_acpi.c

[Xen-devel] [PATCH v8 02/16] libxl/arm: prepare for constructing ACPI tables

It only constructs the ACPI tables for 64-bit ARM DomU when user enables acpi because 32-bit DomU doesn't support ACPI. And the generation codes are only built for 64-bit toolstack. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei

[Xen-devel] [PATCH v8 13/16] libxl/arm: Add ACPI module

Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base address of ACPI tables from it. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- docs/misc/arm/device-tree/acpi.txt | 24

[Xen-devel] [PATCH v8 08/16] libxl/arm: Factor MPIDR computing codes out as a helper

Factor MPIDR computing codes out as a helper, so it could be shared between DT and ACPI. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- tools/libxl/libxl_arm.c | 8 +--- tools/libxl/libxl_arm.h

Re: [Xen-devel] [PATCH 15/24] xl: allow to set the ratelimit value online for Credit2

On 17/08/16 18:19, Dario Faggioli wrote: > Last part of the wiring necessary for allowing to > change the value of the ratelimit_us parameter online, > for Credit2 (like it is already for Credit1). > > Signed-off-by: Dario Faggioli > --- > Cc: Ian Jackson

Re: [Xen-devel] [PATCH 12/24] xen: libxc: allow to set the ratelimit value online

On 17/08/16 18:18, Dario Faggioli wrote: > The main purpose of the patch is to provide the xen-libxc > plumbing necessary to be able to change the value of the > ratelimit_us parameter online, for Credit2 (like it is > already for Credit1). > > While there: > - mention in the Xen logs when rate

Re: [Xen-devel] [PATCH 16/24] xen: sched: factor affinity helpers out of sched_credit.c

On 17/08/16 18:19, Dario Faggioli wrote: > make it possible to use the various helpers from other > schedulers, e.g., for implementing soft affinity within > them. > > Since we are touching the code, also make it start using > variables called v for struct_vcpu*, as it is preferrable. > > No

Re: [Xen-devel] [PATCH v2] libxc: fix out of range shift in populate_acpi_pages

On Wed, Sep 28, 2016 at 04:38:19PM +0100, Wei Liu wrote: > unsigned int is only 4-byte long and "4" is treated as int. The shift > would overflow. > > Use unsigned long type, calculate the bits to shift before shifting > instead of shifting twice. > > Caught by clang compilation test. > >

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

flight 101182 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101182/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 101175 test-armhf-armhf-xl-rtds

Re: [Xen-devel] [PATCH v2 02/30] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

>>> On 27.09.16 at 17:56, wrote: > On PVHv2 guests we explicitly want to use native methods for routing > interrupts. > > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can > route physical interrupts (even from emulated devices) over event channels.

[Xen-devel] [qemu-mainline test] 101192: trouble: broken/fail/pass

9907e6 ec044a8 Author: Peter Maydell <peter.mayd...@linaro.org> Date: Wed Sep 28 17:44:05 2016 +0100 Merge remote-tracking branch 'remotes/kraxel/tags/pull-input-20160928-1' into staging input queue: ps2 kbd cleanups and improvements # gpg: Signature made Wed 28 Sep 201

[Xen-devel] [PATCH v8 11/13] x86: make Xen early boot code relocatable

Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2

[Xen-devel] [PATCH v8 07/13] x86: add multiboot2 protocol support for EFI platforms

This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v8 - suggestions/fixes: - use __bss_start(%rip)/__bss_end(%rip) instead of of .startof.(.bss)(%rip)/$.sizeof.(.bss)

[Xen-devel] [PATCH v8 06/13] efi: create new early memory allocator

There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory

[Xen-devel] [PATCH v8 01/13] x86: add multiboot2 protocol support

Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v8 09/13] x86: change default load address from 1 MiB to 2 MiB

Subsequent patches introducing relocatable early boot code play with page tables using 2 MiB huge pages. If load address is not aligned at 2 MiB then code touching such page tables must have special cases for start and end of Xen image memory region. So, let's make life easier and move default

[Xen-devel] [PATCH v8 10/13] x86/setup: use XEN_IMG_OFFSET instead of...

..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index

[Xen-devel] [PATCH v8 13/13] x86: add multiboot2 protocol support for relocatable images

Add multiboot2 protocol support for relocatable images. Only GRUB2 with "multiboot2: Add support for relocatable images" patch understands that feature. Older multiboot protocol (regardless of version) compatible loaders ignore it and everything works as usual. Signed-off-by: Daniel Kiper

[Xen-devel] [PATCH v8 08/13] x86/boot: implement early command line parser in C

Current early command line parser implementation in assembler is very difficult to change to relocatable stuff using segment registers. This requires a lot of changes in very weird and fragile code. So, reimplement this functionality in C. This way code will be relocatable out of the box (without

[Xen-devel] [PATCH v8 04/13] x86: properly calculate xen ELF end of image address

Currently xen ELF end of image address is calculated using first line from "nm -nr xen/xen-syms" output. However, potentially it may contain symbol address not related to the end of image in any way. It can happen if a symbol is introduced with address larger than _end symbol address. Such

[Xen-devel] [PATCH v8 05/13] efi: build xen.gz with EFI code

Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement of both boot protocols. Currently, PE file

[Xen-devel] [PATCH v8 00/13] x86: multiboot2 protocol support

Hi, I am sending eight version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS platforms) and

[Xen-devel] [PATCH v8 12/13] x86/boot: rename sym_phys() to sym_offs()

This way macro name better describes its function. Currently it is used to calculate symbol offset in relation to the beginning of Xen image mapping. However, value returned by sym_offs() for a given symbol is not always equal its physical address. There is no functional change. Suggested-by:

[Xen-devel] [PATCH v8 02/13] efi: create efi_enabled()

First of all we need to differentiate between legacy BIOS and EFI platforms during runtime, not during build, because one image will have legacy and EFI code and can be executed on both platforms. Additionally, we need more fine grained knowledge about EFI environment and check for EFI platform

[Xen-devel] [PATCH v8 03/13] x86: allow EFI reboot method neither on EFI platforms...

..nor EFI platforms with runtime services enabled. Suggested-by: Jan Beulich Signed-off-by: Daniel Kiper Acked-by: Jan Beulich --- v6 - suggestions/fixes: - move this commit behind "efi: create efi_enabled()" commit

Re: [Xen-devel] [PATCH] libxc: use PRI_xen_pfn in xc_dom_load_acpi

On 09/28/2016 03:28 PM, Wei Liu wrote: > This fixes compilation on ARM. > > Signed-off-by: Wei Liu Reviewed-by: Boris Ostrovsky > --- > Cc: Ian Jackson > Cc: Boris Ostrovsky > --- >

Re: [Xen-devel] [PATCH] libxc: use PRI_xen_pfn in xc_dom_load_acpi

On Wed, Sep 28, 2016 at 06:18:05PM -0400, Boris Ostrovsky wrote: > On 09/28/2016 03:28 PM, Wei Liu wrote: > > This fixes compilation on ARM. > > > > Signed-off-by: Wei Liu > > Reviewed-by: Boris Ostrovsky > Thanks, pushed.

Re: [Xen-devel] [PATCH] pub-headers: reduce C99 dependencies

Hi Jan, On 28/09/2016 05:00, Jan Beulich wrote: For consumers not using (fully) C99-aware compilers, limit the number of places where tweaking of the headers would be necessary: Introduce and use xen_mk_ullong(), allowing its helper macro to be overridden at once. For now don't touch

Re: [Xen-devel] [PATCH 17/24] xen: credit2: soft-affinity awareness in runq_tickle()

On 17/08/16 18:19, Dario Faggioli wrote: > This is done by means of the "usual" two steps loop: > - soft affinity balance step; > - hard affinity balance step. > > The entire logic implemented in runq_tickle() is > applied, during the first step, considering only the > CPUs in the vcpu's soft

[Xen-devel] [xen-unstable-smoke test] 101194: regressions - FAIL

flight 101194 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101194/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 101184 Tests which

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

This run is configured for baseline tests only. flight 67776 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67776/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair

[Xen-devel] [qemu-mainline baseline-only test] 67779: regressions - FAIL

This run is configured for baseline tests only. flight 67779 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67779/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 15

[Xen-devel] [PATCH] libxc: use PRI_xen_pfn in xc_dom_load_acpi

This fixes compilation on ARM. Signed-off-by: Wei Liu --- Cc: Ian Jackson Cc: Boris Ostrovsky --- tools/libxc/xc_dom_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxc/xc_dom_core.c

[Xen-devel] [xen-unstable-smoke test] 101193: regressions - FAIL

flight 101193 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101193/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 101184 Tests which

Re: [Xen-devel] [PATCH v1] hvmloader, pci: Don't try to relocate memory if 64-bit BAR is bigger than 4GB

.. snip.. >> +{ >> +/* If bigger than 4GB, don't try to put under 4GB. */ >> +if ( is_64bar && bar_sz > (1ull<<32) ) > > Clearly at the very least this should be >=. However, even when > it's a 2Gb BAR, we won't be able to fit it (as it can't go at

[Xen-devel] [xen-4.7-testing test] 101188: regressions - FAIL

flight 101188 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101188/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 101076

[Xen-devel] [xen-unstable-smoke test] 101187: regressions - FAIL

flight 101187 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101187/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 101184 Tests which

Re: [Xen-devel] [PATCH v4] vm_event: Implement ARM SMC events

On Wed, Sep 28, 2016 at 5:58 PM, Stefano Stabellini wrote: > On Fri, 16 Sep 2016, Tamas K Lengyel wrote: >> The ARM SMC instructions are already configured to trap to Xen by default. In >> this patch we allow a user-space process in a privileged domain to receive >>

[Xen-devel] [PATCH v5] vm_event: Implement ARM SMC events

The ARM SMC instructions are already configured to trap to Xen by default. In this patch we allow a user-space process in a privileged domain to receive notification of when such event happens through the vm_event subsystem by introducing the PRIVILEGED_CALL type. The intended use-case for this

[Xen-devel] [xen-unstable-smoke test] 101195: tolerable all pass - PUSHED

flight 101195 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101195/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] [PATCH v2 1/2] hvmloader: Use MB(x) and GB(x) macros

instead of hardcoding values. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Ian Jackson Cc: Wei Liu v2: New submission ---

[Xen-devel] [PATCH v2 2/2] hvmloader, pci: Don't try to relocate memory if 64-bit BAR is bigger than ~2GB

Where ~2GB is actually 2GB minus MMIO space used for emulated devices and minus APIC space. There is no point. We can try to balloon out the memory between hvm_info->low_mem_pgend to pci_mem_end and we will never be able have a hole big enough for 2GB MMIO. As we can't go lower than 0x8000

[Xen-devel] [PATCH v2] Enhancements to hvmloader for Xen 4.8

Hey! These two patches came about as I was doing PCI passthrough with rather large BAR regions and finding a lot of ballooning - which was unnecessary as we only have 1744MB of MMIO space under 4GB and all of the ballooning in and out would not help squeeze in a 2GB BAR or higher in there.

Re: [Xen-devel] [PATCH v4] vm_event: Implement ARM SMC events

On Wed, 28 Sep 2016, Tamas K Lengyel wrote: > On Wed, Sep 28, 2016 at 5:58 PM, Stefano Stabellini > wrote: > > On Fri, 16 Sep 2016, Tamas K Lengyel wrote: > >> The ARM SMC instructions are already configured to trap to Xen by default. > >> In > >> this patch we allow a

Re: [Xen-devel] [PATCH v4] vm_event: Implement ARM SMC events

On Wed, Sep 28, 2016 at 6:10 PM, Stefano Stabellini wrote: > On Wed, 28 Sep 2016, Tamas K Lengyel wrote: >> On Wed, Sep 28, 2016 at 5:58 PM, Stefano Stabellini >> wrote: >> > On Fri, 16 Sep 2016, Tamas K Lengyel wrote: >> >> The ARM SMC

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

flight 101189 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101189/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 101074

Re: [Xen-devel] [DOC v6] PV Calls protocol design

On Wed, Sep 14, 2016 at 04:45:01PM -0700, Stefano Stabellini wrote: > Hi all, Hey! I took a look at the spec. It overall looks good with a detail of how each of the sub-commands works in exhaustive detail (which is awesome!). Please see below for some questions, comments. > > This is the

[Xen-devel] [PATCH v8 16/16] libxl/arm: Add the size of ACPI tables to maxmem

Here it adds the ACPI tables size to set the target maxmem to avoid providing less available memory for guest. Signed-off-by: Shannon Zhao --- tools/libxl/libxl.c | 45 - tools/libxl/libxl_arch.h| 5 +

[Xen-devel] [PATCH v8 15/16] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

The guest kernel will get the event channel interrupt information via domain param HVM_PARAM_CALLBACK_IRQ. Initialize it here. Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- tools/libxl/libxl_arm.c

[Xen-devel] [PATCH v8 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update them in evtchn_fixup(). Also use HVM_PARAM_CALLBACK_IRQ_TYPE_MASK in hvm_set_callback_via(). Cc: Jan Beulich Cc: Andrew Cooper Signed-off-by: Shannon Zhao

[Xen-devel] [PATCH v8 10/16] libxl/arm: Construct ACPI FADT table

Signed-off-by: Shannon Zhao Acked-by: Julien Grall Acked-by: Wei Liu --- tools/libxl/libxl_arm_acpi.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/tools/libxl/libxl_arm_acpi.c

[Xen-devel] [xen-unstable-smoke test] 101198: tolerable all pass - PUSHED

flight 101198 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101198/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [Qemu-devel] [PATCH] xenpv: Fix qemu_uuid compiling error

On Wed, 09/28 17:03, Stefano Stabellini wrote: > On Tue, 27 Sep 2016, Eric Blake wrote: > > On 09/27/2016 04:20 AM, Fam Zheng wrote: > > > 9c5ce8db2 switched the type of qemu_uuid and this should have followed. > > > Fix it. > > > > > > Signed-off-by: Fam Zheng > > > --- > > >

Re: [Xen-devel] [PATCH v4 2/6] VMX: Properly handle pi when all the assigned devices are removed

> >> > >> So you continue using pausing, and I continue to miss the argumentation > >> of why you can't do without (even if previously the discussion was for > >> patch 4, but it obviously applies here as well). > > > > I think this case is slightly different. Here we need to call > >

  1   2   3   >