> Hi James,
>
> I found a PPT file named “XenRT-XenSource’s Xen testing infrastructure”
>written by you, I have a few questions and hope you could help me there.
> I am looking for a better test tool for Xen, so I recently setup XenRT in a
>debian VM according to this website:
>http://wiki.xen
In the course of backporting other XSA fixes to very old trees I had
noticed that the XSA-155 had shrunk to just the change to
xen/include/public/io/ring.h at some point, which didn't seem right.
Clearly up to 4.5 the situation of blktap1 is the same as that of
blktap2, i.e. one would think it also
From: Wen Congyang
Secondary(restore side) is running under COLO, we also need
postcopy/suspend callbacks.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxc/include/xenguest.h | 10 ++
tools/libxl/libxl_save_msgs_gen.pl | 4 ++-
From: Wen Congyang
In normal migration, the qemu state is passed to qemu as a parameter.
With COLO, secondary vm is running. So we will do the following steps
at every checkpoint:
1. suspend both primary vm and secondary vm
2. sync the state
3. resume both primary vm and secondary vm
Primary will
From: Wen Congyang
In COLO mode, both VMs are running, and are considered in sync if the
visible network traffic is identical. After some time, they fall out of
sync.
At this point, the two VMs have definitely diverged. Lets call the
primary dirty bitmap set A, while the secondary dirty bitmap
From: Wen Congyang
Secondary vm is running in COLO mode, we need to send secondary
vm's dirty page information to primary host at checkpoint, so we
have to enable qemu logdirty on secondary.
libxl__domain_suspend_common_switch_qemu_logdirty() is to enable
qemu logdirty. But it uses libxl__domain
From: Wen Congyang
Used by secondary to send it's dirty bitmap to primary under COLO.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
docs/specs/libxc-migration-stream.pandoc | 26 +++-
tools/libxc/xc_sr_common.c | 31 --
From: Wen Congyang
Usage: disk =
['...,colo,colo-host=xxx,colo-port=xxx,colo-export=xxx,active-disk=xxx,hidden-disk=xxx...']
For QEMU block replication details:
http://wiki.qemu.org/Features/BlockReplication
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
From: Wen Congyang
In COLO mode, secondary needs to send the following data to primary:
1. In libxl
Secondary sends the following CHECKPOINT_CONTEXT to primary:
CHECKPOINT_SVM_SUSPENDED, CHECKPOINT_SVM_READY and CHECKPOINT_SVM_RESUMED
2. In libxc
Secondary sends the dirty pfn list to pri
From: Wen Congyang
Add a new option -c to the command 'xl remus'. If you want
to use COLO HA instead of Remus HA, please use -c option.
Update man pages to reflect the addition of a new option to
'xl remus' command.
Also add a new option -c to the internal command 'xl migrate-receive'.
Signed-
This patchset implemented the COLO feature for Xen.
For detail/install/use of COLO feature, refer to:
http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
You can get the codes from here:
https://github.com/Pating/xen/tree/changlox/colo_v11
Changlog from v10 to v11
1. Rebased to then upst
From: Wen Congyang
Under COLO, we are doing checkpoint on demand, if this
callback returns 1, we will take another checkpoint.
0 indicates unexpected error.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxc/include/xenguest.h | 18 +
>>> On 03.03.16 at 18:59, wrote:
> On Tue, Mar 01, 2016 at 09:17:25AM -0700, Jan Beulich wrote:
>> >>> On 25.02.16 at 15:56, wrote:
>> > --- a/tools/firmware/hvmloader/hvmloader.c
>> > +++ b/tools/firmware/hvmloader/hvmloader.c
>> > @@ -365,8 +365,26 @@ int main(void)
>> >
>> > if ( bi
From: Wen Congyang
This is used by primay to read records sent by secondary.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_internal.h| 4 ++
tools/libxl/libxl_stream_read.c | 94 +++
From: Wen Congyang
It is pure refactoring and no functional changes.
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
Acked-by: Wei Liu
---
tools/libxl/libxl_save_callout.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl
From: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_colo_save.c | 124 +++---
tools/libxl/libxl_internal.h | 1 +
2 files changed, 117 insertions(+), 8 deletions(-)
diff --git a/
From: Wen Congyang
read_record() could be used by primary to read dirty bitmap
record sent by secondary under COLO.
When used by save side, we need to pass the backchannel fd
instead of ctx->fd to read_record(), so we added a fd param to
it.
No functional changes.
CC: Andrew Cooper
Signed-off-b
From: Wen Congyang
We will do the following things again and again:
1. Suspend primary vm
a. Suspend primary vm
b. do postsuspend
c. Read CHECKPOINT_SVM_SUSPENDED sent by secondary
2. Checkpoint
a. Write emulator xenstore data and emulator context
b. Write checkpoint end record
3.
From: Wen Congyang
Add cmdline switches to 'xl migrate-receive' command to specify
a domain-specific hotplug script to setup COLO proxy.
Add a new config var 'colo.default.agentscript' to xl.conf, that
allows the user to override the default global script used to
setup COLO proxy.
Signed-off-by
From: Wen Congyang
implement COLO nic subkind.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/hotplug/Linux/Makefile | 1 +
tools/hotplug/Linux/colo-proxy-setup | 135 +++
tools/libxl/Makefile | 1 +
too
From: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_colo_restore.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_colo_restore.c b/tools/libxl/libxl_
From: Wen Congyang
Add back channel support to write stream. If the write stream is
a back channel stream, this means the write stream is used by
Secondary to send some records back.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_d
From: Wen Congyang
We will use qemu block replication, and qemu provides some qmp commands
to prepare replication, start replication, get replication error, and
stop replication. Introduce new API to execute these qmp commands.
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
Acked-by:
From: Wen Congyang
a. call callbacks resume/checkpoint/suspend while secondary vm
status is consistent with primary
b. send dirty pfn list to primary when checkpoint under colo
c. send store gfn and console gfn to xl before resuming secondary vm
Signed-off-by: Yang Hongyang
Signed-off-by: We
From: Wen Congyang
Secondary vm is running in colo mode. So we will do
the following things again and again:
1. Resume secondary vm
a. Send CHECKPOINT_SVM_READY to master.
b. If it is not the first resume, call libxl__checkpoint_devices_preresume().
c. If it is the first resume(resume ri
From: Wen Congyang
add colo readme, refer to
http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
Acked-by: Ian Campbell
Acked-by: Wei Liu
---
docs/README.colo | 9 +
1 file changed, 9 inser
From: Wen Congyang
setup/teardown of COLO proxy module.
we use netlink to communicate with proxy module.
About colo-proxy module:
https://lkml.org/lkml/2015/6/18/32
How to use:
http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
S
From: Wen Congyang
After suspend primary vm, get dirty bitmap on secondary vm,
and send pages both dirty on primary/secondary to secondary.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
CC: Andrew Cooper
---
tools/libxc/xc_sr_common.h | 2 +
tools/li
From: Wen Congyang
preresume, postresume and checkpoint
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_colo.h | 4 +++
tools/libxl/libxl_colo_proxy.c | 62 ++
2 files changed, 66 inser
From: Wen Congyang
It is the negotiation record for COLO.
Primary->Secondary:
control_id 0x: Secondary VM is out of sync, start a new checkpoint
Secondary->Primary:
0x0001: Secondary VM is suspended
0x0002: Secondary VM is ready
From: Wen Congyang
Use qemu block replication as our block replication solution.
Note that guest must be paused before starting COLO, otherwise,
the disk won't be consistent between primary and secondary.
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
--
>>> On 03.03.16 at 19:55, wrote:
>> On 2 Mar 2016, at 22:45, Daniel Izquierdo wrote:
>> On 01/03/16 18:04, Lars Kurth wrote:
>>> Q2: What is the scope? Do the number count
>>> - the # files someone reviewed
>>> - the # patches someone reviewed
>>> - the # series someone reviewed
>>
>> The number
flight 85295 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85295/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85080
Tests which di
> On 4 Mar 2016, at 08:42, Jan Beulich wrote:
>
On 03.03.16 at 19:55, wrote:
>>> On 2 Mar 2016, at 22:45, Daniel Izquierdo wrote:
>>> On 01/03/16 18:04, Lars Kurth wrote:
Q2: What is the scope? Do the number count
- the # files someone reviewed
- the # patches someone revie
>>> On 04.03.16 at 10:05, wrote:
>> On 4 Mar 2016, at 08:42, Jan Beulich wrote:
> On 03.03.16 at 19:55, wrote:
On 2 Mar 2016, at 22:45, Daniel Izquierdo wrote:
On 01/03/16 18:04, Lars Kurth wrote:
> It may be better to use the following definition (although, others may
>
>>> On 04.03.16 at 03:45, wrote:
> On March 04, 2016 7:59am, wrote:
>> On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote:
>> > @@ -788,10 +787,10 @@ static bool_t __init
>> > set_iommu_interrupt_handler(struct amd_iommu *iommu)
>> > return 0;
>> > }
>> >
>> > -spin_lock_irqsave(&
>>> On 04.03.16 at 01:11, wrote:
> On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote:
>> @@ -167,10 +176,12 @@ static int queue_invalidate_wait(struct iommu
>> *iommu,
>> start_time = NOW();
>> while ( poll_slot != QINVAL_STAT_DONE )
>> {
>> -if ( NOW() > (sta
On Mon, Feb 29, 2016 at 03:50:19PM -0800, Andy Lutomirski wrote:
> x86_64 has very clean espfix handling on paravirt: espfix64 is set
> up in native_iret, so paravirt systems that override iret bypass
> espfix64 automatically. This is robust and straightforward.
>
> x86_32 is messier. espfix is
On Mon, Feb 29, 2016 at 03:50:20PM -0800, Andy Lutomirski wrote:
> It no longer has any users.
>
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/kernel/asm-offsets.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
> index 8
>>> On 03.03.16 at 17:48, wrote:
> if ( !ret )
> {
> ret = schedule_cpu_switch(cpu, NULL);
> if ( ret )
> -{
> cpumask_clear_cpu(cpu, &cpupool_free_cpus);
> -goto out;
> +else
> +{
> +cpupool_moving_cpu = -1;
>>> On 03.03.16 at 17:48, wrote:
> Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
> called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
> to achieve this by pinning the running thread to cpu 0, but in Dom0
> this is not enough: the vcpu must be pinned to physical
>>> On 03.03.16 at 17:48, wrote:
> Add a XEN_VCPUAFFINITY_FORCE flag to xen_domctl_vcpuaffinity structure
> which will allow to undo a SCHEDOP_pin_override in case of a driver
> error of the hardware domain which didn't do the expected
> SCHEDOP_pin_override with cpu < 0 which would have done the
On 04/03/16 10:42, Jan Beulich wrote:
On 03.03.16 at 17:48, wrote:
>> if ( !ret )
>> {
>> ret = schedule_cpu_switch(cpu, NULL);
>> if ( ret )
>> -{
>> cpumask_clear_cpu(cpu, &cpupool_free_cpus);
>> -goto out;
>> +else
>> +
>>> On 04.03.16 at 10:54, wrote:
> On 04/03/16 10:42, Jan Beulich wrote:
> On 03.03.16 at 17:48, wrote:
>>> if ( !ret )
>>> {
>>> ret = schedule_cpu_switch(cpu, NULL);
>>> if ( ret )
>>> -{
>>> cpumask_clear_cpu(cpu, &cpupool_free_cpus);
>>> -
>>> On 04.03.16 at 07:15, wrote:
> From: Shannon Zhao
>
> Estimate the memory required for loading acpi/efi tables in Dom0. Make
> the length of each table aligned with 64bit. Alloc the pages to store
> the new created EFI and ACPI tables and free these pages when
> destroying domain.
>
> Cc: J
create ^
thanks
On Fri, Mar 04, 2016 at 03:37:10AM +, Xu, Quan wrote:
> On February 16, 2016 1:08am, wrote:
> > On Mon, Feb 15, 2016 at 10:45:48AM -0600, Doug Goldstein wrote:
> > > On 2/15/16 10:28 AM, Wei Liu wrote:
> > > > On Sun, Feb 14, 2016 at 07:39:35PM +1100, Steven Haigh wrote:
> >
Processing commands for x...@bugs.xenproject.org:
> create ^
Created new bug #52 rooted at
`<945ca011ad5f084cbea3e851c0ab28894b859...@shsmsx101.ccr.corp.intel.com>'
Title: `Re: [Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01'
> thanks
Finished processing.
Modified/created Bugs:
- 52
>>> On 04.03.16 at 07:15, wrote:
> From: Shannon Zhao
>
> Add a new delivery type:
> val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
> To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
> bit 9 stands the interrupt polarity is active low(1) or high(0).
>
> Cc: Jan Be
>>> On 04.03.16 at 07:15, wrote:
> From: Shannon Zhao
>
> It needs to map platform or amba device mmio to Dom0 on ARM. But when
> booting with ACPI, it can't get the mmio region in Xen due to lack of
> AML interpreter to parse DSDT table. Therefore, let Dom0 call a
> hypercall to map mmio region
>>> On 04.03.16 at 07:15, wrote:
> From: Naresh Bhat
>
> Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.
>
> Cc: Jan Beulich
> Signed-off-by: Naresh Bhat
> Signed-off-by: Shannon Zhao
> ---
> v5: make ACPI selectable option
> ---
> xen/arch/arm/Kconfig | 9
At 09:28 -0700 on 03 Mar (1456997339), Jan Beulich wrote:
> 1: honor cache attribute pinning for RAM only
> 2: remove unnecessary indirection from hvm_get_mem_pinned_cacheattr()
> 3: adjust hvm_set_mem_pinned_cacheattr() error indications
> 4: limit flushing on cache attribute pinning adjustments
>
>>> On 04.03.16 at 02:17, wrote:
> On 2016/3/3 23:44, Stefano Stabellini wrote:
>> On Thu, 3 Mar 2016, Shannon Zhao wrote:
>>> > From: Shannon Zhao
>>> >
>>> > While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
>>> > refactors the functions preinit_xen_time and init_xen_time
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> On 2016/3/3 23:44, Stefano Stabellini wrote:
> > On Thu, 3 Mar 2016, Shannon Zhao wrote:
> >> > From: Shannon Zhao
> >> >
> >> > While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
> >> > refactors the functions preinit_xen_time and in
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> On 2016/3/1 20:49, Stefano Stabellini wrote:
> > On Tue, 1 Mar 2016, Jan Beulich wrote:
> > > >>> On 01.03.16 at 03:35, wrote:
> >> >
> >>> > >
> >>> > > On 2016/2/29 22:36, Jan Beulich wrote:
> >>> > > On 29.02.16 at 15:25,
> >>> > >>>
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Parth Dixit
>
> Create a helper function for mapping with cached attributes and
> read-write range.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> v5: use p2m_access_rw and rename to map_regions_rw
Reviewed-by: Stefano Stab
On Fri, 4 Mar 2016, Jan Beulich wrote:
> >>> On 04.03.16 at 07:15, wrote:
> > From: Shannon Zhao
> >
> > Estimate the memory required for loading acpi/efi tables in Dom0. Make
> > the length of each table aligned with 64bit. Alloc the pages to store
> > the new created EFI and ACPI tables and fr
On 03/03/16 18:03, Anthony PERARD wrote:
> In this series, there are plenty of places where one blob loaded by libxl
> to be consume by hvmloader is called acpi_module or acpi_table... where in
> fact it is only the DSDT table. I think I'm going to do some renaming to
> include "dsdt" into those na
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> These tables are aligned with 64bit.
>
> Signed-off-by: Shannon Zhao
> ---
> v5: make the return value type and variable type consistent
> ---
> xen/arch/arm/acpi/lib.c| 15 +++
> xen/include/asm-arm/acpi.h | 6 +
On Fri, 4 Mar 2016, Jan Beulich wrote:
> >>> On 04.03.16 at 07:15, wrote:
> Overall I wonder whether this wouldn't help PVH on x86 too,
> where we currently do some hackery to (not even completely)
> map MMIO into Dom0's p2m. In such a case perhaps
> map_dev_mmio_regions() should become a general
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Prepare EFI system table for Dom0 to describe the information of UEFI.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
> v5: move to efi-dom0.c
> ---
> xen/arch/arm/domain_build.c
Previous patch using all available features calculate xstate_comp_offsets.
This is wrong.This patch fix this bug by calculating the xstate_comp_offset
based on xcomp_bv of current guest.
Also, the xstate_comp_offset should take alignment into consideration.
Signed-off-by: Shuai Ruan
Reported-by:
flight 85306 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85080
Tests which di
As was previously explained[1], SMAP (and with less relevance also
SMEP) is not compatible with 32-bit PV guests which aren't aware/
prepared to be run with that feature enabled. Andrew's original
approach either sacrificed architectural correctness for making
32-bit guests work again or by disabli
>>> On 04.03.16 at 12:00, wrote:
> On Fri, 4 Mar 2016, Jan Beulich wrote:
>> >>> On 04.03.16 at 07:15, wrote:
>> Overall I wonder whether this wouldn't help PVH on x86 too,
>> where we currently do some hackery to (not even completely)
>> map MMIO into Dom0's p2m. In such a case perhaps
>> map_de
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Create a few EFI memory descriptors to tell Dom0 the RAM region
> information, ACPI table regions and EFI tables reserved resions.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> v5: move to efi-dom0.c
> ---
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Create a DT for Dom0 for ACPI-case only. DT contains minimal required
> informations such as Dom0 bootargs, initrd, efi description table and
> address of uefi memory table.
>
> Also port the document of this device tree bindings f
The offset at which components xsaved by xsave[sc] are not fixed.
So when when a save with v->fpu_dirtied set is followed by one
with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data
written by the lazy one.
The solution is when xsave[sc] is enabled and taking xcr0_accum into
consider
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Interrupt information is described in DSDT and is not available at the
> time of booting. Check if the interrupt is permitted to access and set
> the interrupt type, route it to guest dynamically only for SPI
> and Dom0.
>
> Signed
Make sure the near JMP/CALL check doesn't consume uninitialized
data, not even in a benign way. And relax the length check at once.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -174,7 +174,7 @@ static void __init apply_alternatives(st
m
Since such guests' kernel code runs in ring 1, their memory accesses,
at the paging layer, are supervisor mode ones, and hence subject to
SMAP/SMEP checks. Such guests cannot be expected to be aware of those
two features though (and so far we also don't expose the respective
feature flags), and hen
Alternatives patching code picks the most suitable NOPs for the
running system, so simply use it to replace the pre-populated ones.
Use an arbitrary, always available feature to key off from.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/en
This is slightly more efficient than loading 64-bit quantities.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -313,6 +313,13 @@ static always_inline void stac(void)
987:
.endm
+#define LOAD_ONE_REG(reg, compat) \
+.if !(compat); \
+
On Fri, 4 Mar 2016, Jan Beulich wrote:
> >>> On 04.03.16 at 12:00, wrote:
> > On Fri, 4 Mar 2016, Jan Beulich wrote:
> >> >>> On 04.03.16 at 07:15, wrote:
> >> Overall I wonder whether this wouldn't help PVH on x86 too,
> >> where we currently do some hackery to (not even completely)
> >> map MMI
On Fri, 4 Mar 2016, Jan Beulich wrote:
> >>> On 04.03.16 at 07:15, wrote:
> > From: Naresh Bhat
> >
> > Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.
> >
> > Cc: Jan Beulich
> > Signed-off-by: Naresh Bhat
> > Signed-off-by: Shannon Zhao
> > ---
> > v5: make ACPI select
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Naresh Bhat
>
> Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.
>
> Cc: Jan Beulich
> Signed-off-by: Naresh Bhat
> Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
> v5: make ACPI selectable option
> ---
> xe
On March 04, 2016 5:29pm, wrote:
> >>> On 04.03.16 at 03:45, wrote:
> > On March 04, 2016 7:59am, wrote:
> >> On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote:
> >> > @@ -788,10 +787,10 @@ static bool_t __init
> >> > set_iommu_interrupt_handler(struct amd_iommu *iommu)
> >> > return 0;
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new member in gic_hw_operations which is used to deny Dom0 access
> to GIC regions.
>
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/gic-v2.c | 31 +++
> xen/arch/arm/gic-v3.c | 44 ++
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Firstly it permits full MMIO capabilities for Dom0. Then deny MMIO
> access of Xen used devices, such as UART, GIC, SMMU. Currently, it only
> denies the MMIO access of UART and GIC regions. For other Xen used
> devices it could be
On Fri, 4 Mar 2016, Jan Beulich wrote:
> >>> On 04.03.16 at 07:15, wrote:
> > From: Shannon Zhao
> >
> > Add a new delivery type:
> > val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
> > To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
> > bit 9 stands the interrupt
>>> On 01.03.16 at 16:44, wrote:
> On Mon, 29 Feb 2016, Jan Beulich wrote:
>> it just occurred to me that 4.5.2 has been a while back, and indeed
>> 4.5.3 would be due later this week. This may be a little too eager,
>> but I'd like to aim at getting this out at least some time next week.
>> Besid
>>> On 04.03.16 at 13:09, wrote:
> On Fri, 4 Mar 2016, Jan Beulich wrote:
>> >>> On 04.03.16 at 07:15, wrote:
>> > From: Shannon Zhao
>> >
>> > Add a new delivery type:
>> > val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
>> > To the flag, bit 8 stands the interrupt mode is edge(1) or le
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> Signed-off-by: Shannon Z
>>> On 03.03.16 at 15:14, wrote:
> @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN, 106)/* Transport endpoint
> is already connected */
> XEN_ERRNO(ENOTCONN, 107)/* Transport endpoint is not connected */
> XEN_ERRNO(ETIMEDOUT, 110)/* Connection timed out */
>
> -#undef XEN_ERRNO
>
On Fri, 4 Mar 2016, Jan Beulich wrote:
> >>> On 04.03.16 at 13:09, wrote:
> > On Fri, 4 Mar 2016, Jan Beulich wrote:
> >> >>> On 04.03.16 at 07:15, wrote:
> >> > From: Shannon Zhao
> >> >
> >> > Add a new delivery type:
> >> > val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
> >> > To the
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Sometimes it needs to check if there is a subnode of given node in FDT
> by given name. Introduce this helper to get the subnode if it exists.
>
> CC: Rob Herring
> Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
>
>>> On 04.03.16 at 13:24, wrote:
On 03.03.16 at 15:14, wrote:
>> @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN, 106)/* Transport endpoint
>> is already
> connected */
>> XEN_ERRNO(ENOTCONN, 107)/* Transport endpoint is not connected */
>> XEN_ERRNO(ETIMEDOUT,110)/* Conn
On 04/03/16 12:28, Jan Beulich wrote:
On 04.03.16 at 13:24, wrote:
> On 03.03.16 at 15:14, wrote:
>>> @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN, 106)/* Transport endpoint
>>> is already
>> connected */
>>> XEN_ERRNO(ENOTCONN,107)/* Transport endpoint is not connected
>>> On 04.03.16 at 13:50, wrote:
> On 04/03/16 12:28, Jan Beulich wrote:
> On 04.03.16 at 13:24, wrote:
>> On 03.03.16 at 15:14, wrote:
@@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN,106)/* Transport endpoint
is already
>>> connected */
XEN_ERRNO(ENOTCONN, 107)
>>> On 23.02.16 at 12:22, wrote:
> Patches 1 and 2 are meant to go in. Patch 3 is a prerequisite to patch
> 4 and may go in as well, but patch 4 is RFC because with the Pericom
> board I have MSI doesn't appear to function. Since it also does not
> work in baremetal Linux when doing the trivial ad
flight 85117 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
flight 85320 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85320/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85080
Tests which di
>>> On 04.03.16 at 12:00, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -934,8 +934,14 @@ long arch_do_domctl(
> goto vcpuextstate_out;
> }
>
> -expand_xsave_states(v, xsave_area,
> -
On Fri, 2016-03-04 at 11:54 +, Xu, Quan wrote:
> On March 04, 2016 5:29pm, wrote:
> > On March 04, 2016 7:59am, wrote:
> >
> > > Also I'd highlight the below modification:
> > > -if ( !spin_trylock(&pcidevs_lock) )
> > > -return -ERESTART;
> > > -
> > > +pcidevs_lock();
> > >
>>> On 04.03.16 at 12:22, wrote:
> The offset at which components xsaved by xsave[sc] are not fixed.
> So when when a save with v->fpu_dirtied set is followed by one
> with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data
> written by the lazy one.
>
> The solution is when xsave[sc]
On Fri, Mar 04, 2016 at 01:21:19AM -0700, Jan Beulich wrote:
> In the course of backporting other XSA fixes to very old trees I had
> noticed that the XSA-155 had shrunk to just the change to
> xen/include/public/io/ring.h at some point, which didn't seem right.
> Clearly up to 4.5 the situation of
>>> On 04.03.16 at 14:59, wrote:
> On Fri, 2016-03-04 at 11:54 +, Xu, Quan wrote:
>> On March 04, 2016 5:29pm, wrote:
>> > To be honest, changes like this would better not be buried in a big
>> > rework like
>> > the one here. Make it a prereq patch, where you then will kind of
>> > automatic
This run is configured for baseline tests only.
flight 44216 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44216/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm3 host-install(3)
>>> On 04.03.16 at 15:09, wrote:
> On Fri, Mar 04, 2016 at 01:21:19AM -0700, Jan Beulich wrote:
>> In the course of backporting other XSA fixes to very old trees I had
>> noticed that the XSA-155 had shrunk to just the change to
>> xen/include/public/io/ring.h at some point, which didn't seem righ
While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
refactors the functions preinit_xen_time and init_xen_time. But it
wrongly moves the platform_get_irq from init_xen_time to
preinit_dt_xen_time and this will cause booting failure.
So move platform_get_irq back to init_xen_tim
flight 85121 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004
build-armhf
1 - 100 of 184 matches
Mail list logo
