Re: [Xen-devel] [PATCH 2/7] iommu: make use of type-safe BFN and MFN in exported functions

>>> On 12.02.18 at 11:47, wrote: > This patch modifies the declaration of the entry points to the IOMMU > sub-system to use bfn_t and mfn_t in place of unsigned long. A subsequent > patch will similarly modify the methods in the iommu_ops structure. > > NOTE: Since (with

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Minutes

On 15/03/18 13:48, George Dunlap wrote: > On Wed, Mar 14, 2018 at 6:06 PM, Lars Kurth wrote: >> ## Meeting format >> >> Andy: no suggestions to change >> Lars: the only issue I noticed that we had people >> Video conference: do this as needed (most conference services have

Re: [Xen-devel] [PATCH v5 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

>>> On 15.03.18 at 16:03, wrote: > Hi Jan, > > On 15/03/18 08:06, Jan Beulich wrote: > On 14.03.18 at 19:20, wrote: >>> @@ -95,11 +101,17 @@ static unsigned int max_order(const struct domain *d) >>> return min(order, MAX_ORDER + 0U); >>> }

Re: [Xen-devel] [PATCH v5 12/14] x86/HVM: use x86emul_write_xcr()

On 15/03/18 13:12, Jan Beulich wrote: > ... instead of directly calling handle_xsetbv(), to make use of the > additional checking there. > > Also don't call hvm_monitor_crX(XCR0, ...) for indexes other than zero > anymore. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew

Re: [Xen-devel] [PATCH v3 3/6] x86: log XPTI enabled status

On 13/03/18 13:48, Jan Beulich wrote: > At the same time also report the state of the two defined > ARCH_CAPABILITIES MSR bits. To avoid further complicating the > conditional around that printk(), drop it (it's a debug level one only > anyway). > > Signed-off-by: Jan Beulich >

Re: [Xen-devel] [PATCH v3 4/6] x86/XPTI: use %r12 to write zero into xen_cr3

On 13/03/18 13:49, Jan Beulich wrote: > Now that we zero all registers early on all entry paths, use that to > avoid a couple of immediates here. > > Signed-off-by: Jan Beulich > --- > We may want to consider eliminating a few more $0 this way. But > especially for byte ones

Re: [Xen-devel] [PATCH v5 04/16] xen/arm: mm: Remove unused M2P code

On Wed, Mar 14, 2018 at 6:19 PM, wrote: > From: Julien Grall > > Arm does not have an M2P and very unlikely to get one in the future, > therefore don't keep defines that are not necessary in the common code. > > At the same time move the remaining M2P

Re: [Xen-devel] [PATCH v5 12/14] x86/HVM: use x86emul_write_xcr()

On 03/15/2018 11:43 AM, Andrew Cooper wrote: > On 15/03/18 13:12, Jan Beulich wrote: >> ... instead of directly calling handle_xsetbv(), to make use of the >> additional checking there. >> >> Also don't call hvm_monitor_crX(XCR0, ...) for indexes other than zero >> anymore. >> >> Signed-off-by:

Re: [Xen-devel] [PATCH v5 01/16] x86/mm: skip incrementing mfn if it is not a valid mfn

On Thu, Mar 15, 2018 at 12:16 PM, Andrew Cooper wrote: > On 15/03/18 07:52, Jan Beulich wrote: > On 14.03.18 at 19:31, wrote: >>> On 14/03/18 18:19, julien.gr...@arm.com wrote: From: Wei Liu The

Re: [Xen-devel] [PATCH 3/7] iommu: push use of type-safe BFN and MFN into iommu_ops

>>> On 12.02.18 at 11:47, wrote: > @@ -612,12 +612,12 @@ static int __must_check iommu_flush_iotlb(struct domain > *d, > if ( iommu_domid == -1 ) > continue; > > -if ( page_count != 1 || bfn == bfn_x(INVALID_BFN) ) > +if (

[Xen-devel] [xen-4.9-testing test] 120681: regressions - trouble: broken/fail/pass

flight 120681 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120681/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale broken test-amd64-i386-xl-qemut-ws16-amd64

Re: [Xen-devel] [PATCH v9 11/11] vpci/msix: add MSI-X handlers

On Thu, Mar 15, 2018 at 06:45:58AM -0600, Jan Beulich wrote: > >>> On 15.03.18 at 13:01, wrote: > > On Wed, Mar 14, 2018 at 11:04:00AM -0600, Jan Beulich wrote: > >> >>> On 14.03.18 at 15:04, wrote: > >> > +process_pending_softirqs(); > >>

[Xen-devel] [PATCH 2/5] tools/firmware: #define IPXE_PATH

--with-system-ipxe allows the user to specify ipxe rom. If this option is given, use system supplied ipxe instead of building and installing our own version Plumbing for using iPXE roms, specified with --with-system-ipxe, doesn't exist and will be added in future commits. Re-run of autoconf is

[Xen-devel] [PATCH 3/5] libxc: Allow loading of firmware modules for HVM guest

This allows to load iPXE rom as a firmware module, instead of requiring it to be embedded into hvmloader. Signed-off-by: Anoob Soman --- tools/libxc/xc_dom_x86.c | 13 + 1 file changed, 13 insertions(+) diff --git a/tools/libxc/xc_dom_x86.c

[Xen-devel] [PATCH 4/5] libxl: Load iPXE ROM from a file

Load iPXE ROM from a file pointed to by IPXE_PATH. If --with-system-ipxe is not specified default Xen firmware directory is picked up as IPXE_PATH Signed-off-by: Anoob Soman --- tools/libxl/libxl_dom.c | 12 tools/libxl/libxl_internal.h | 1 +

[Xen-devel] [PATCH 1/5] tools/firmware: Build ipxe as a standalone ROM

This patches doesn't get rid of etherboot[] from roms.inc. Instead, makes a standalone iPXE rom, which will later be used by hvmloader (when all the plubming to use standalone iPXE rom are in place) Signed-off-by: Anoob Soman --- tools/firmware/Makefile | 3 +++

[Xen-devel] Make iPXE a standalone ROM

Make the iPXE ROM be built as a standalone ROM, rather than being embedded into hvmloader and pass the iPXE ROM to hvmloader via module, in the same way as OVMF/SeaBIOS are currently passed Introduce a ./configure --with-system-ipxe=$path option This allows us to disentangle iPXE from hvmloader,

[Xen-devel] [PATCH v3 2/4] tools: libxl/xl: allow to get/set Credit1's vcpu_migration_delay

Make it possible to get and set a (Credit1) scheduler's vCPU migration delay via the SCHEDOP sysctl, from both libxl and xl (no change needed in libxc). Signed-off-by: Dario Faggioli Acked-by: Wei Liu --- Cc: Ian Jackson Cc:

[Xen-devel] [PATCH v3 3/4] tools: xenpm: continue to support {set, get}-vcpu-migration-delay

Now that it is possible to get and set the migration delay via the SCHEDOP sysctl, use that in xenpm, instead of the special purpose libxc interface (which will be removed in a following commit). The sysctl, however, requires a cpupool-id argument, for knowing on which scheduler it is operating

[Xen-devel] [PATCH v3 0/4] xen/tools: sched: Credit1: improve handling of vCPU migration delay

Hi, Version 3 of this series. v2: https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg02177.html v1: https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg02029.html I think I've addressed all the review comments (basically, the time conversion issues spotted by

Re: [Xen-devel] [PATCH] xen/x86: Implement enable_nmis() in C

On 15/03/18 17:02, Jan Beulich wrote: On 15.03.18 at 17:43, wrote: >> +static inline void enable_nmis(void) >> +{ >> +unsigned long tmp; >> + >> +asm volatile ( "mov %%rsp, %[sp] \n\t" >> + "push %[ss] \n\t" >> +

Re: [Xen-devel] [PATCH v3 5/6] x86/XPTI: reduce .text.entry

On 13/03/18 13:50, Jan Beulich wrote: > --- a/xen/arch/x86/x86_64/entry.S > +++ b/xen/arch/x86/x86_64/entry.S > @@ -14,8 +14,6 @@ > #include > #include > > -.section .text.entry, "ax", @progbits > - > /* %rbx: struct vcpu */ > ENTRY(switch_to_kernel) > leaq

[Xen-devel] [PATCH 5/5] hvmloader: Use iPXE ROM loaded from a standalone file

splatering of mkhex-ed etherboot inside hvmloader/rombios is removed, instead hvmloader/rombios now relies on iPXE ROM to be added,loaded as a module. Signed-off-by: Anoob Soman --- tools/firmware/hvmloader/Makefile| 7 +-- tools/firmware/hvmloader/config.h|

[Xen-devel] [PATCH v3 4/4] xen/libxc: suppress direct access to Credit1's migration delay

Removes special purpose access to Credit1 vCPU migration delay parameter. This fixes a build breakage, occuring when Xen is configured with SCHED_CREDIT=n. Signed-off-by: Dario Faggioli Acked-by: Wei Liu --- Cc: Ian Jackson

Re: [Xen-devel] [PATCH v5 03/14] x86emul: abstract out XCRn accesses

On 15/03/18 13:04, Jan Beulich wrote: > --- a/xen/arch/x86/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate.c > @@ -42,3 +42,50 @@ > }) > > #include "x86_emulate/x86_emulate.c" > + > +int x86emul_read_xcr(unsigned int reg, uint64_t *val, > + struct x86_emulate_ctxt *ctxt) >

Re: [Xen-devel] [PATCH] xen/pirq: fix error path cleanup when binding MSIs

On Mi, 2018-02-28 at 09:19 +, Roger Pau Monne wrote: > Current cleanup in the error path of xen_bind_pirq_msi_to_irq is > wrong. First of all there's an off-by-one in the cleanup loop, which > can lead to unbinding wrong IRQs. > > Secondly IRQs not bound won't be freed, thus leaking IRQ

Re: [Xen-devel] [PATCH v3 2/6] x86: disable XPTI when RDCL_NO

On 13/03/18 13:48, Jan Beulich wrote: > Use the respective ARCH_CAPABILITIES MSR bit, but don't expose the MSR > to guests yet. > > Signed-off-by: Jan Beulich > Tested-by: Juergen Gross > Reviewed-by: Juergen Gross Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH v5 02/16] xen/arm: setup: use maddr_to_mfn rather than _mfn(paddr_to_pfn(...))

On Wed, Mar 14, 2018 at 6:19 PM, wrote: > From: Julien Grall > > The construction _mfn(paddr_to_pfn(...)) can be simplified by using > maddr_to_mfn. > > Signed-off-by: Julien Grall Reviewed-by: George Dunlap

Re: [Xen-devel] [PATCH v3 3/6] x86: log XPTI enabled status

>>> On 15.03.18 at 16:56, wrote: > On 13/03/18 13:48, Jan Beulich wrote: >> At the same time also report the state of the two defined >> ARCH_CAPABILITIES MSR bits. To avoid further complicating the >> conditional around that printk(), drop it (it's a debug level one

Re: [Xen-devel] [PATCH v5 07/16] xen/x86: mm: Switch x86/mm.c to use typesafe for virt_to_mfn

On Wed, Mar 14, 2018 at 6:20 PM, wrote: > From: Julien Grall > > No functional change intended. If you end up respinning this you might also add: "While we're here, use PFN_DOWN() rather than open coding it." > > Signed-off Julien Grall

Re: [Xen-devel] [PATCH v5 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

On 03/14/2018 06:20 PM, julien.gr...@arm.com wrote: > From: Julien Grall > > The function populate_pt_range is used to populate in advance the > page-table but it will not do the actual mapping. So passing the MFN in > parameter is pointless. Note that the only caller pass

[Xen-devel] 2018 Xen Project Developer and Design Summit: CfP open from now to April 13, Event is held June 20-22, 2018 in Nanjing, China

Dear Community Members, I am excited to announce that registration and the call for proposals is open for Xen Project Developer and Design Summit 2018. The event will be held in at the Crowne Plaza Nanjing, China from June 20-22, 2018. The Xen Project Developer and Design Summit will follow

Re: [Xen-devel] [PATCH v5 03/14] x86emul: abstract out XCRn accesses

>>> On 15.03.18 at 16:41, wrote: > On 15/03/18 13:04, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate.c >> @@ -42,3 +42,50 @@ >> }) >> >> #include "x86_emulate/x86_emulate.c" >> + >> +int x86emul_read_xcr(unsigned int reg,

Re: [Xen-devel] [PATCH v5 03/16] xen/arm: mm: Use gaddr_to_gfn rather than _gfn(paddr_to_pfn(...))

On Wed, Mar 14, 2018 at 6:19 PM, wrote: > From: Julien Grall > > The construction _gfn(paddr_to_pfn(...)) can be simplified by using > gaddr_to_gfn. > > Signed-off-by: Julien Grall Not sure if "simplified" is the right word

Re: [Xen-devel] [PATCH v5 05/16] xen/arm: mm: Remove unused relinquish_shared_pages

On Wed, Mar 14, 2018 at 6:19 PM, wrote: > From: Julien Grall > > relinquish_shared_pages is never called on Arm. > > Signed-off-by: Julien Grall Reviewed-by: George Dunlap

Re: [Xen-devel] [PATCH v3 4/6] x86/XPTI: use %r12 to write zero into xen_cr3

>>> On 15.03.18 at 17:02, wrote: > On 13/03/18 13:49, Jan Beulich wrote: >> Now that we zero all registers early on all entry paths, use that to >> avoid a couple of immediates here. >> >> Signed-off-by: Jan Beulich >> --- >> We may want to consider

Re: [Xen-devel] [PATCH 4/7] vtd: add lookup_page method to iommu_ops

>>> On 12.02.18 at 11:47, wrote: > This patch adds a new method to the VT-d IOMMU implementation to find the > MFN currently mapped by the specified BFN. This functionality will be used > by a subsequent patch. How come this is VT-d only? The same is going to be needed

Re: [Xen-devel] [PATCH v5 10/16] xen/mm: Switch map_pages_to_xen to use MFN typesafe

Hi George, On 15/03/18 16:50, George Dunlap wrote: On 03/14/2018 06:20 PM, julien.gr...@arm.com wrote: diff --git a/xen/common/vmap.c b/xen/common/vmap.c index 11785ffb0a..04f5db386d 100644 --- a/xen/common/vmap.c +++ b/xen/common/vmap.c @@ -9,6 +9,10 @@ #include #include +/* Override

Re: [Xen-devel] [OSSTEST PATCH v2 09/19] ts-debian-fixup: merge origin extra= to our own

On Wed, Mar 07, 2018 at 03:06:19PM +, Ian Jackson wrote: > Wei Liu writes ("[OSSTEST PATCH v2 09/19] ts-debian-fixup: merge origin > extra= to our own"): > > The original extra= was not removed, so there were two extra= in the > > resulting config file. > > > > It wasn't a problem for xl

Re: [Xen-devel] [PATCH v3 4/6] x86/XPTI: use %r12 to write zero into xen_cr3

On 15/03/18 16:39, Jan Beulich wrote: On 15.03.18 at 17:02, wrote: >> On 13/03/18 13:49, Jan Beulich wrote: >>> Now that we zero all registers early on all entry paths, use that to >>> avoid a couple of immediates here. >>> >>> Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v5 10/14] x86/HVM: do actual CMPXCHG in hvmemul_cmpxchg()

On 15/03/18 13:10, Jan Beulich wrote: > ..., at least as far as currently possible, i.e. when a mapping can be > obtained. > > Signed-off-by: Jan Beulich > Reviewed-by: Paul Durrant Acked-by: Andrew Cooper

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

On 03/15/2018 10:22 AM, Joao Martins wrote: > All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and > changing only the acpi_id. For processors which P-state coordination type > is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information > (_PSD), because Xen will

Re: [Xen-devel] [PATCH v9 09/11] vpci/msi: add MSI handlers

>>> On 15.03.18 at 16:54, wrote: > On Thu, Mar 15, 2018 at 06:44:13AM -0600, Jan Beulich wrote: >> >>> On 15.03.18 at 12:48, wrote: >> > On Wed, Mar 14, 2018 at 10:51:07AM -0600, Jan Beulich wrote: >> >> >>> On 14.03.18 at 15:04,

[Xen-devel] [PATCH] xen/x86: Implement enable_nmis() in C

I don't recall why I chose to implement this in assembly to begin with, but it can happily live in a static inline instead, and only has two callers. Doing so reduces the quantity of code in .text.entry. Signed-off-by: Andrew Cooper --- Looking at the disassembly,

Re: [Xen-devel] [PATCH v5 10/16] xen/mm: Switch map_pages_to_xen to use MFN typesafe

On 03/14/2018 06:20 PM, julien.gr...@arm.com wrote: > diff --git a/xen/common/vmap.c b/xen/common/vmap.c > index 11785ffb0a..04f5db386d 100644 > --- a/xen/common/vmap.c > +++ b/xen/common/vmap.c > @@ -9,6 +9,10 @@ > #include > #include > > +/* Override macros from asm/page.h to make them

Re: [Xen-devel] [PATCH v5 11/16] xen/mm: Switch some of page_alloc.c to typesafe MFN

On 03/14/2018 06:20 PM, julien.gr...@arm.com wrote: > From: Julien Grall > > No functional change intended. > > Signed-off-by: Julien Grall > Reviewed-by: Wei Liu This patch by itself doesn't look like it actually makes things

Re: [Xen-devel] [PATCH] xen/x86: Implement enable_nmis() in C

>>> On 15.03.18 at 17:43, wrote: > +static inline void enable_nmis(void) > +{ > +unsigned long tmp; > + > +asm volatile ( "mov %%rsp, %[sp] \n\t" > + "push %[ss] \n\t" > + "push %[sp] \n\t" > +

[Xen-devel] [PATCH v2 0/8] Using GitLab CI for build testing

Really early work on switching over to using GitLab CI over Travis CI. GitLab is a competitor to GitHub with some advantages such as an integrated CI system with a lot more flexibility and control. It additionally is fully open sourced unlike GitHub and Travis CI. We can even run an instance if

[Xen-devel] [PATCH RESEND 0/4] xen: sched: optimize exclusive pinning and soft-affinity checking

Hello, Here it is another rather old series of mine. In this case, George has Reviewed-by most of it, but it needed rebasing on top of staging. https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg01850.html And that is exactly what I am doing with this RESEND. George: - I did not

Re: [Xen-devel] [PATCH 4/7] x86/domain: Remove unused parameters from {hvm, pv}_domain_initialise()

On 13/03/18 12:05, Roger Pau Monné wrote: > Maybe this could be: > > if ( is_idle_domain(d) ) > ... > else > { > rc = is_hvm_domain(d) ? hvm_domain_initialise(d) > : pv_domain_initialise(d); > if ( rc ) > goto fail; > } > > But that's maybe out of the

Re: [Xen-devel] [PATCH 7/7] xen/mm: Clean up share_xen_page_with_guest() API

On 13/03/18 14:39, Jan Beulich wrote: On 13.03.18 at 13:28, wrote: >> On Fri, Mar 09, 2018 at 01:18:42PM +, Andrew Cooper wrote: >>> --- a/xen/arch/arm/mm.c >>> +++ b/xen/arch/arm/mm.c >>> @@ -1187,8 +1187,8 @@ unsigned long domain_get_maximum_gpfn(struct domain

[Xen-devel] [PATCH v2 2/8] ci: add Dockerfile for CentOS 7.2

Added a Dockerfile which captures all the necessary dependencies to build Xen on a CentOS 7.2 system. Signed-off-by: Doug Goldstein --- automation/build/centos/7.2.dockerfile | 41 ++- automation/build/centos/CentOS-7.2.repo | 35

[Xen-devel] [PATCH v2 4/8] ci: add Dockerfile for Ubuntu 16.04

Added a Dockerfile which captures all the necessary dependencies to build Xen on a Ubuntu 16.04 system. Signed-off-by: Doug Goldstein --- automation/build/ubuntu/xenial.dockerfile | 47 - 1 file changed, 47 insertions(+) create mode 100644

[Xen-devel] [PATCH v2 1/8] ci: add README and makefile for containers

Add a basic README explaining the containers and how people can use them to locally test with if they see an error in CI and want to reproduce it locally. Added a makefile to help with building and pushing the containers to the container registry. Signed-off-by: Doug Goldstein

[Xen-devel] [PATCH v2 06/45] xen/arm: gic: Split the field state in gic_lr in 2 fields active and pending

From: Julien Grall Mostly making the code nicer to read. Signed-off-by: Julien Grall Reviewed-by: Andre Przywara Signed-off-by: Andre Przywara --- Changes: - Use 1ULL - Remove pointless == *_STATE_*

[Xen-devel] [PATCH v2 19/45] ARM: new VGIC: Add IRQ sync/flush framework

Implement the framework for syncing IRQs between our emulation and the list registers, which represent the guest's view of IRQs. This is done in vgic_sync_from_lrs() and vgic_sync_to_lrs(), which get called on guest entry and exit, respectively. The code talking to the actual GICv2/v3 hardware is

[Xen-devel] [PATCH v2 00/45] New VGIC(-v2) implementation

tl;dr: Coarse changelog below, individual patches have changelogs as well. git branch: http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/vgic-new/v2 git://linux-arm.org/xen-ap.git branch vgic-new/v2 Another update, addressing the review comments. Nothing too outstanding this time,

[Xen-devel] [PATCH v2 02/45] ARM: Implement vcpu_kick()

If we change something in a vCPU that affects its runnability or otherwise needs the vCPU's attention, we might need to tell the scheduler about it. We are using this in one place (vIRQ injection) at the moment, but will need this at more places soon. So let's factor out this functionality, using

[Xen-devel] [PATCH v2 03/45] xen/arm: gic: Fix indentation in gic_update_one_lr

From: Julien Grall Signed-off-by: Julien Grall Reviewed-by: Andre Przywara Signed-off-by: Andre Przywara --- Changelog v1 ... v2: - Add Andre's reviewed-by xen/arch/arm/gic-vgic.c | 4 ++-- 1 file

[Xen-devel] [PATCH v2 08/45] ARM: GIC: extend LR read/write functions to cover EOI and source

From: Julien Grall So far our LR read/write functions do not handle the EOI bit and the source CPUID bits in an LR, because the current VGIC implementation does not use them. Extend the gic_lr data structure to hold these bits of information by using a union to

[Xen-devel] [PATCH v2 22/45] ARM: new VGIC: Add MMIO handling framework

Add an MMIO handling framework to the VGIC emulation: Each register is described by its offset, size (or number of bits per IRQ, if applicable) and the read/write handler functions. We provide initialization macros to describe each GIC register later easily. Separate dispatch functions for read

[Xen-devel] [PATCH v2 01/45] ARM: VGIC: rename gic_event_needs_delivery()

gic_event_needs_delivery() is not named very intuitively, especially the gic_ prefix is somewhat misleading. Rename it to vgic_vcpu_pending_irq(), which makes it clear that this relates to the virtual GIC and is about interrupts. Also add a VCPU parameter, which makes the code more flexible in the

[Xen-devel] [PATCH v2 09/45] ARM: GIC: Allow tweaking the active and pending state of an IRQ

When playing around with hardware mapped, level triggered virtual IRQs, there is the need to explicitly set the active or pending state of an interrupt at some point. To prepare the GIC for that, we introduce a set_active_state() and a set_pending_state() function to let the VGIC manipulate the

[Xen-devel] [PATCH v2 12/45] ARM: evtchn: Handle level triggered IRQs correctly

The event channel IRQ has level triggered semantics, however the current VGIC treats everything as edge triggered. To correctly process those IRQs, we have to lower the (virtual) IRQ line at some point in time, depending on whether ther interrupt condition still prevails. Check the per-VCPU

[Xen-devel] [PATCH v2 07/45] xen/arm: GIC: Only set pirq in the LR when hw_status is set

From: Julien Grall The field pirq should only be valid when the virtual interrupt is associated to a physical interrupt. This change will help to extend gic_lr for supporting specific virtual interrupt field (e.g eoi, source) that clashes with the PIRQ field.

[Xen-devel] [PATCH v2 20/45] ARM: new VGIC: Add GICv2 world switch backend

Processing maintenance interrupts and accessing the list registers are dependent on the host's GIC version. Introduce vgic-v2.c to contain GICv2 specific functions. Implement the GICv2 specific code for syncing the emulation state into the VGIC registers. This also adds the hook to let Xen setup

[Xen-devel] [PATCH v2 42/45] ARM: new VGIC: vgic-init: implement vgic_init

This patch allocates and initializes the data structures used to model the vgic distributor and virtual cpu interfaces. At that stage the number of IRQs and number of virtual CPUs is frozen. Implement the various functions that the Xen arch code is expecting to call during domain and VCPU setup to

[Xen-devel] [PATCH v2 24/45] ARM: new VGIC: Add CTLR, TYPER and IIDR handlers

Those three registers are v2 emulation specific, so their implementation lives entirely in vgic-mmio-v2.c. Also they are handled in one function, as their implementation is pretty simple. We choose to piggy-back on the existing KVM identification registers, but use a different variant (major

[Xen-devel] [PATCH v2 23/45] ARM: new VGIC: Add GICv2 MMIO handling framework

Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers using the initializer macros provided by the VGIC MMIO framework. Provide a function to register the GICv2 distributor registers to the Xen MMIO framework. The actual handler functions are still stubs in this patch. This is based

[Xen-devel] [PATCH v2 26/45] ARM: new VGIC: Add PENDING registers handlers

The pending register handlers are shared between the v2 and v3 emulation, so their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. For level triggered interrupts the real line level is unaffected by this write, so we keep this state separate and

[Xen-devel] [PATCH v2 25/45] ARM: new VGIC: Add ENABLE registers handlers

As the enable register handlers are shared between the v2 and v3 emulation, their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. This introduces a vgic_sync_hardware_irq() function, which updates the physical side of a hardware mapped virtual

[Xen-devel] [PATCH v2 27/45] ARM: new VGIC: Add ACTIVE registers handlers

The active register handlers are shared between the v2 and v3 emulation, so their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. Since activation/deactivation of an interrupt may happen entirely in the guest without it ever exiting, we need some

[Xen-devel] [PATCH v2 18/45] ARM: new VGIC: Add IRQ sorting

Adds the sorting function to cover the case where you have more IRQs to consider than you have LRs. We consider their priorities. This uses the new sort_list() implementation imported from Linux. This is based on Linux commit 8e4447457965, written by Christoffer Dall. Signed-off-by: Andre

[Xen-devel] [PATCH v2 31/45] ARM: new VGIC: Add SGIR register handler

Triggering an IPI via this register is v2 specific, so the implementation lives entirely in vgic-mmio-v2.c. This is based on Linux commit 55cc01fb9004, written by Andre Przywara. Signed-off-by: Andre Przywara --- Changelog v1 ... v2: - remove stray rebase artefact

[Xen-devel] [PATCH v2 33/45] ARM: new VGIC: Handle hardware mapped IRQs

The VGIC supports virtual IRQs to be connected to a hardware IRQ, so when a guest EOIs the virtual interrupt, it affects the state of that corresponding interrupt on the hardware side at the same time. Implement the interface that the Xen arch/core code expects to connect the virtual and the

[Xen-devel] [PATCH v2 16/45] ARM: new VGIC: Implement virtual IRQ injection

Provide a vgic_queue_irq_unlock() function which decides whether a given IRQ needs to be queued to a VCPU's ap_list. This should be called whenever an IRQ becomes pending or enabled, either as a result of a hardware IRQ injection, from devices emulated by Xen (like the architected timer) or from

[Xen-devel] [PATCH v2 04/45] xen/arm: vgic: Override the group in lr everytime

From: Julien Grall At the moment, write_lr is assuming the caller will set correctly the group. However the group should always be 0 when the guest is using vGICv2 and 1 for vGICv3. As the caller should not care about the group, override it directly. With that change,

[Xen-devel] [PATCH v2 13/45] ARM: vPL011: Use the VGIC's level triggered IRQs handling if available

The emulated ARM SBSA UART is using level triggered IRQ semantics, however the current VGIC can only handle edge triggered IRQs, really. Disable the existing workaround for this problem in case we have the new VGIC in place, which can properly handle level triggered IRQs. Signed-off-by: Andre

[Xen-devel] [PATCH v2 17/45] Add list_sort() routine from Linux

This pulls in Linux' list_sort.c, which is a merge sort implementation for linked lists. Apart from adding a full featured license header and adjusting the #include file, nothing has been changed in this code. Signed-off-by: Andre Przywara --- Changelog v1 ... v2: -

[Xen-devel] [PATCH v2 21/45] ARM: new VGIC: Implement vgic_vcpu_pending_irq

Tell Xen whether a particular VCPU has an IRQ that needs handling in the guest. This is used to decide whether a VCPU is runnable or if a hypercall should be preempted to let the guest handle the IRQ. This is based on Linux commit 90eee56c5f90, written by Eric Auger. Signed-off-by: Andre

[Xen-devel] [PATCH v2 30/45] ARM: new VGIC: Add TARGET registers handlers

The target register handlers are v2 emulation specific, so their implementation lives entirely in vgic-mmio-v2.c. We copy the old VGIC behaviour of assigning an IRQ to the first VCPU set in the target mask instead of making it possibly pending on multiple VCPUs. We update the physical affinity of

[Xen-devel] [PATCH v2 40/45] ARM: new VGIC: vgic-init: register VGIC

This patch implements the function which is called by Xen when it wants to register the virtual GIC. This also implements vgic_max_vcpus() for the new VGIC, which reports back the maximum number of VCPUs a certain GIC model supports. Signed-off-by: Andre Przywara ---

[Xen-devel] [PATCH v2 34/45] ARM: new VGIC: Add event channel IRQ handling

The Xen core/arch code relies on two abstracted functions to inject an event channel IRQ and to query its pending state. Implement those to query the state of the new VGIC implementation. Signed-off-by: Andre Przywara Acked-by: Julien Grall ---

[Xen-devel] [PATCH v2 41/45] ARM: new VGIC: Add vgic_v2_enable

Enable the VGIC operation by properly initialising the registers in the hypervisor GIC interface. This is based on Linux commit f7b6985cc3d0, written by Eric Auger. Signed-off-by: Andre Przywara --- Changelog v1 ... v2: - move patch from later part in the series

[Xen-devel] [PATCH v2 28/45] ARM: new VGIC: Add PRIORITY registers handlers

The priority register handlers are shared between the v2 and v3 emulation, so their implementation goes into vgic-mmio.c, to be easily referenced from the v3 emulation as well later. This is based on Linux commit 055658bf48fc, written by Andre Przywara. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v2 05/45] xen/arm: gic: Use bool instead of uint8_t for the hw_status in gic_lr

From: Julien Grall hw_status can only be 1 or 0. So convert to a bool. Signed-off-by: Julien Grall Reviewed-by: Andre Przywara Signed-off-by: Andre Przywara --- Changes: - Remove == *LR_HW as it is

[Xen-devel] [PATCH v2 15/45] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

The new VGIC implementation centers around a struct vgic_irq instance per virtual IRQ. Provide a function to retrieve the right instance for a given IRQ number and (in case of private interrupts) the right VCPU. This also includes the corresponding put function, which does nothing for private

[Xen-devel] [PATCH v2 14/45] ARM: new VGIC: Add data structure definitions

Add a new header file for the new and improved GIC implementation. The big change is that we now have a struct vgic_irq per IRQ instead of spreading all the information over various bitmaps in the ranks. We include this new header conditionally from within the old header file for the time being

[Xen-devel] [PATCH v2 45/45] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

Now that we have both the old VGIC prepared to cope with a sibling and the code for the new VGIC in place, lets add a Kconfig option to enable the new code and wire it into the Xen build system. This will add a compile time option to use either the "old" or the "new" VGIC. In the moment this is

[Xen-devel] [PATCH v2 35/45] ARM: new VGIC: Handle virtual IRQ allocation/reservation

To find an unused virtual IRQ number Xen uses a scheme to track used virtual IRQs. Implement this interface in the new VGIC to make the Xen core/arch code happy. This is actually somewhat VGIC agnostic, so is mostly a copy of the code from the old VGIC. But it has to live in the VGIC files, so we

[Xen-devel] [PATCH v2 5/8] ci: add Dockerfile for Debian jessie

Added a Dockerfile which captures all the necessary dependencies to build Xen on a Debian jessie system. Signed-off-by: Doug Goldstein --- automation/build/debian/jessie.dockerfile | 47 - 1 file changed, 47 insertions(+) create mode 100644

[Xen-devel] [PATCH v2 6/8] ci: add Dockerfile for Debian stretch

Added a Dockerfile which captures all the necessary dependencies to build Xen on a Debian stretch system. Signed-off-by: Doug Goldstein --- automation/build/debian/stretch.dockerfile | 47 +++- 1 file changed, 47 insertions(+) create mode 100644

[Xen-devel] [PATCH v2 7/8] ci: add cfg to use GitLab CI to build

Added a GitLab CI config which has a lot more flexibility to allow us to test a lot more distro configurations than Travis can and even build test on FreeBSD. Signed-off-by: Doug Goldstein --- .gitlab-ci.yml | 164 ++- 1 file

[Xen-devel] [PATCH v2 3/8] ci: add Dockerfile for Ubuntu 14.04

Added a Dockerfile which captures all the necessary dependencies to build Xen on a Ubuntu 14.04 system. Signed-off-by: Doug Goldstein --- automation/build/ubuntu/trusty.dockerfile | 47 - 1 file changed, 47 insertions(+) create mode 100644

[Xen-devel] [PATCH v2 8/8] ci: add new bits to MAINTAINERS combine with Travis

Created a new section just called 'CI' since this is adding GitLab CI and still leaving the old Travis CI files around. This consolidates the two sections and adds the new files as well as adding another Travis file that was missing. Signed-off-by: Doug Goldstein ---

Re: [Xen-devel] [PATCH v2 1/3] sndif: Introduce protocol version

On Wed, Mar 14, 2018 at 06:02:43PM +0200, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Protocol version was referenced in the protocol description, > but missed its definition. Fix this by adding a constant > for current protocol version. >

Re: [Xen-devel] [PATCH v5 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

On 03/14/2018 06:20 PM, julien.gr...@arm.com wrote: > From: Julien Grall > > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make

Re: [Xen-devel] [PATCH v5 11/16] xen/mm: Switch some of page_alloc.c to typesafe MFN

Hi George, Thank you for the review. On 15/03/18 17:02, George Dunlap wrote: On 03/14/2018 06:20 PM, julien.gr...@arm.com wrote: From: Julien Grall No functional change intended. Signed-off-by: Julien Grall Reviewed-by: Wei Liu

[Xen-devel] [PATCH v2 32/45] ARM: new VGIC: Add SGIPENDR register handlers

As this register is v2 specific, its implementation lives entirely in vgic-mmio-v2.c. This register allows setting the source mask of an IPI. This is based on Linux commit ed40213ef9b0, written by Andre Przywara. Signed-off-by: Andre Przywara Reviewed-by: Julien Grall

[Xen-devel] [PATCH v2 38/45] ARM: new VGIC: Implement arch_move_irqs()

When a VCPU moves to another CPU, we need to adjust the target affinity of any hardware mapped vIRQs, to observe our "physical-follows-virtual" policy. Implement arch_move_irqs() to adjust the physical affinity of all hardware mapped vIRQs targetting this VCPU. Signed-off-by: Andre Przywara

  1   2   3   >