On 03/15/2018 10:17 PM, Konrad Rzeszutek Wilk wrote:
+ **
+ *Back to front events delivery
+ **
+ * In order to deliver a
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
test-amd64-amd64-qemuu-nest
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 li
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.
Xe
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: https://gitlab.com/cardoe/xen/pipelin
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 git://xenbits.xen.org/qemu-xen-traditi
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 4
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 87a1f65e80cf183a87072
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
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,
St
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, I'l
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 1
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
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 +++-
tools/libxl/libxl_x86.c | 6 ++
2 files ch
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 libxl__arch_domain_construct_memmap() earlier,
before xc_
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 a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0b65dab..b46bd1d 100644
---
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: Ma
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
https://lkml.org/lkml
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
---
Changelog v1 ... v2:
-
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
---
C
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.
Signed-off-by
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 slig
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 Acked-by:
xen/arch/arm/vgic/vgic.c | 25 +++
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 | 8
1 file change
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: Julien Grall
---
Changelog
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 IRQ.
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 e
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 c
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
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 revisi
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
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 co
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 res
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
Reviewed-by: J
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
---
Changelog v1 ... v2:
- Add Acked-by:
xen/arch/arm
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/arch/arm/vgic/vgic-v2.c | 6
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
---
Changelo
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 th
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 a
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/arch/arm/vgic/vgic-init.
To synchronize level triggered interrupts which are mapped into a guest,
we need to update the virtual line level at certain points in time.
For a hardware mapped interrupt the GIC is the only place where we can
easily access this information.
Implement a gic_hw_operations member to return the pend
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 Przywar
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/arch/arm/vgic/vgic-mmio-v
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 physic
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 MM
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:
- split out to just contain Linu
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 Przywara
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.
Signed-off-by: Julien Grall
Review
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
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 sta
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 evtchn_
The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we have to sync the state of the interrupt condition at certain
points to catch when the line goes low and we can remove the vtimer vIRQ
from the vGIC
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, write_lr is now behaving li
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 Przy
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/arch/arm/gic-v2.c | 15 +++
xen/arch/arm/gic-v3.c |
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 a
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,
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 t
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 pointless
- Add Andre's reviewed-by
xen/arch/arm/gic-v2.c | 9 +
xen/arch/arm/gic
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 inter
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 to
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 changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/g
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 differentiate field used depending
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 an
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
>>> *d)
>>> return g
> +
> **
> + *Back to front events delivery
> +
> **
> + * In order to deliver asynchronous events from back to front a s
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 xen_arch_domainconfig *config)
>>
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.
>
> Signed-off-by: Oleksandr Andrus
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 scope
On 13/03/18 14:42, Julien Grall wrote:
> Hi,
>
> On 12/03/18 16:32, Wei Liu wrote:
>> On Sun, Mar 11, 2018 at 07:59:16PM +, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 03/09/2018 01:18 PM, Andrew Cooper wrote:
ARM guests are HVM and have hardware assisted paging. There are no
PV gu
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 1
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
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 (e.g., in flags) facts like a vcpu being
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 open
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 (basically, at
every scheduli
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
parameter, for better flex
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 (of
Credit1 and Cred
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 a
soft affinity. I.e
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 ap
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
>>> +++ b/xen/commo
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 tha
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 automation/build/debian/stret
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 changed, 164 insertion
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
---
MAINTAINERS | 16 ++-
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 automation/build/debian/jessie
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
---
automation/bui
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 automation/build/ubuntu/trusty.
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 ++-
2 files changed,
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 automation/build/ubuntu/xenial.
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 page_to_mfn and mfn_to_page re
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
This patch by itself doesn't look like it actually makes th
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
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc
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 George).
Right now, vCPU migration delay is controlled by
the vcpu_migration_delay boot parameter. This means
the same value will always be used for every instance
of Credit1, in any cpupool that will be created.
Also, in order to get and set such value, a special
purpose libxc interface is defined, and us
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 on
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: George Dunlap
Cc: Andrew Cooper
---
Changes from v2:
* drop a redund
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 b/tools/libxc/xc_dom_x86.c
index 0b65dab..
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 +
tools/libxl/libxl_paths.c| 9
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 +++
tools/firmware/hvmloade
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,
1 - 100 of 246 matches
Mail list logo
