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

flight 120734 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120734/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken

Re: [Xen-devel] [PATCH v3 1/6] x86: NOP out XPTI entry/exit code when it's not in use

On 15/03/18 20:44, Andrew Cooper wrote: > On 13/03/18 13:47, Jan Beulich wrote: >> Introduce a synthetic feature flag to use alternative instruction >> patching to NOP out all code on entry/exit paths. Having NOPs here is >> generally better than using conditional branches. >> >> Also change the

[Xen-devel] Request for Xen SeaBIOS git head / branch to follow or include Xen staging tag

Hi, Could there please be a branch of the Xen SeaBIOS repository to track or include the latest tag used by Xen staging? Just for ease of use. All the other Xen dependency repositories do this. Xen staging currently points to SeaBIOS rel-1.10.2. This is not in a named head on the repository.

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

Hi, I have some suggestions / queries. I package Xen using GitLab CI for my use: https://gitlab.com/archlinux-packages-johnth/xen/pipelines My examples here are just mock-ups and not tested. On Fri, 16 Mar 2018, at 04:21, Doug Goldstein wrote: > Example run:

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-win10-i386

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-win10-i386 testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [xen-4.10-testing test] 120706: regressions - trouble: blocked/broken/fail/pass

flight 120706 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120706/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 broken test-amd64-i386-freebsd10-amd64

[Xen-devel] [ovmf test] 120727: all pass - PUSHED

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

[Xen-devel] [rumprun test] 120715: regressions - FAIL

flight 120715 rumprun real [real] http://logs.test-lab.xenproject.org/osstest/logs/120715/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754 build-i386-rumprun

[Xen-devel] Xen ARM Community Call Wednesday 4th April 4PM UTC

Hi all, I suggest to have the next community call on Wednesday 4th April 4PM UTC. Keep in mind that due to Daylight Savings Time 4PM UTC is the usual time slot: 9AM California, 5PM UK. Does it work for everybody? If you have any specific topics to discuss, please reply to this email. Cheers,

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

On Wed, 14 Mar 2018, Stefano Stabellini wrote: > After looking at the test results, which are good for arm, and > considering that master hasn't passed yet after 2 more days, I agree > with Julien: I think we should not release 4.9.2 and 4.7.5 without the > arm64 spectre patches. At this point,

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

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

[Xen-devel] [xen-4.8-testing test] 120695: regressions - trouble: broken/fail/pass

flight 120695 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120695/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-amd64-pvgrub broken test-amd64-i386-qemuu-rhel6hvm-amd

[Xen-devel] [PATCH v3 3/4] libxl: Store PVH guest's e820 map in xc_dom_image

From: Boris Ostrovsky We will later copy it to hvm_start_info. (Also remove stale comment claming that xc_dom_image.start_info_seg is only used for HVMlite guests) Signed-off-by: Boris Ostrovsky --- tools/libxc/include/xc_dom.h | 8

[Xen-devel] [PATCH v3 2/4] libxl: Move libxl__arch_domain_construct_memmap() earlier

From: Boris Ostrovsky Since hvm_start_info has now been expanded to include PVH guest's memory map (i.e. e820) we need to know size of this map by the time we create dom->start_info_seg in alloc_magic_pages_hvm(). To do so we have to call

[Xen-devel] [PATCH v3 4/4] libxc: Pass e820 map to PVH guest via hvm_start_info

From: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Maran Wilson --- tools/libxc/xc_dom_x86.c | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH v3 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. Signed-off-by:

[Xen-devel] [PATCH v3 0/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

Here is the patch series for updating the canonical definition of the hvm_start_info struct corresponding to the discussion happening on the linux-kernel and kvm mailing lists regarding Qemu/KVM use of the PVH entry point: KVM: x86: Allow Qemu/KVM to use PVH entry point

[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

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

map_resources is the last initialization step needed before the first VCPU is run. At that stage the code stores the MMIO base addresses used. Also it registers the respective register frames with the MMIO framework. This is based on Linux commit cbae53e663ea, written by Eric Auger.

[Xen-devel] [PATCH v2 44/45] ARM: new VGIC: Allocate two pages for struct vcpu

At the moment we allocate exactly one page for struct vcpu on ARM, also have a check in place to prevent it growing beyond 4KB. As the struct includes the state of all 32 private (per-VCPU) interrupts, we are at 3840 bytes on arm64 at the moment already. Growing the per-IRQ VGIC structure even

[Xen-devel] [PATCH v2 36/45] ARM: new VGIC: Dump virtual IRQ info

When we dump guest state on the Xen console, we also print the state of IRQs that are on a VCPU. Add the code to dump the state of an IRQ handled by the new VGIC. Signed-off-by: Andre Przywara Acked-by: Julien Grall --- Changelog v1 ... v2: - Add

[Xen-devel] [PATCH v2 39/45] ARM: new VGIC: Add preliminary stub implementation

The ARM arch code requires an interrupt controller emulation to implement vgic_clear_pending_irqs(), although it is suspected that it is actually not necessary. Go with a stub for now to make the linker happy. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic/vgic.c

[Xen-devel] [PATCH v2 37/45] ARM: new VGIC: Provide system register emulation stub

The Xen arch code traps system registers writes from the guest and will relay anything GIC related to the VGIC. Since this affects only GICv3 (which we don't yet emulate), provide a stub implementation of vgic_emulate() for now. Signed-off-by: Andre Przywara Acked-by:

[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 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 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 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 29/45] ARM: new VGIC: Add CONFIG registers handlers

The config 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 79717e4ac09c, written by Andre Przywara. Signed-off-by: Andre Przywara

[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 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 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 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 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 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 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 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 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 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

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

Re: [Xen-devel] [PATCH v2 2/3] sndif: Add explicit back and front synchronization

> + > ** > + *Back to front events delivery > + > ** > + * In order to deliver asynchronous events from back to front a

Re: [Xen-devel] [PATCH 5/7] x86/domain: Optimise the order of actions in arch_domain_create()

On 09/03/18 16:54, Jan Beulich wrote: On 09.03.18 at 14:18, wrote: >> --- a/xen/arch/x86/domain.c >> +++ b/xen/arch/x86/domain.c >> @@ -430,20 +430,37 @@ int arch_domain_create(struct domain *d, unsigned int >> domcr_flags, >> struct

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 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

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

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

Re: [Xen-devel] [PATCH v3 1/6] x86: NOP out XPTI entry/exit code when it's not in use

On 13/03/18 13:47, Jan Beulich wrote: > Introduce a synthetic feature flag to use alternative instruction > patching to NOP out all code on entry/exit paths. Having NOPs here is > generally better than using conditional branches. > > Also change the limit on the number of bytes we can patch in one

Re: [Xen-devel] [PATCH RESEND 1/4] xen: sched: introduce 'adjust_affinity' hook.

Il Gio 15 Mar 2018, 19:35 Dario Faggioli ha scritto: > From: Dario Faggioli > > For now, just as a way to give a scheduler an "heads up", > about the fact that the affinity changed. > > This enables some optimizations, such as pre-computing > and storing

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

On Thu, Mar 15, 2018 at 01:21:08PM -0500, Doug Goldstein wrote: > 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

[Xen-devel] [PATCH RESEND 4/4] xen: sched: simplify (and speedup) checking soft-affinity

From: Dario Faggioli The fact of whether or not a vCPU has a soft-affinity which is effective, i.e., with the power of actually affecting the scheduling of the vCPU itself rarely changes. Very, very rarely, as compared to how often we need to check for the same thing

[Xen-devel] [PATCH RESEND 3/4] xen: sched: improve checking soft-affinity

From: Dario Faggioli Whether or not a vCPU has a soft-affinity which is effective, i.e., with the power of actually affecting the scheduling of the vCPU itself, happens in an helper function, called has_soft_affinity(). Such function takes a custom cpumask as its third

[Xen-devel] [PATCH RESEND 2/4] xen: sched: optimize exclusive pinning case (Credit1 & 2)

From: Dario Faggioli Exclusive pinning of vCPUs is used, sometimes, for achieving the highest level of determinism, and the least possible overhead, for the vCPUs in question. Although static 1:1 pinning is not recommended, for general use cases, optimizing the tickling code

[Xen-devel] [PATCH RESEND 1/4] xen: sched: introduce 'adjust_affinity' hook.

From: Dario Faggioli For now, just as a way to give a scheduler an "heads up", about the fact that the affinity changed. This enables some optimizations, such as pre-computing and storing (e.g., in flags) facts like a vcpu being exclusively pinned to a pcpu, or having or not

[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 v5 10/16] xen/mm: Switch map_pages_to_xen to use MFN typesafe

On 03/15/2018 04:53 PM, Julien Grall wrote: > 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 >>> +++

[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 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 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 ---

[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 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 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 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

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 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

[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

[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 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 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 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 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|

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

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] 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

  1   2   3   >