>>> On 23.03.16 at 18:05, wrote:
> All,
>
> so I've just learned that Windows (at least some versions and some
> of their code paths) use REP MOVSD to read/write the MSI-X table.
> The way at least msixtbl_write() works is not compatible with this
> (msixtbl_read() also seems affected, albeit to
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 using_xsave_compact is enabled and taking xcr0_accum int
Previous patch using all available features calculate comp_offsets.
This is wrong.This patch fix this bug by calculating the comp_offset
based on xcomp_bv of current guest.
Also, the comp_offset should take alignment into consideration.
Signed-off-by: Shuai Ruan
Reported-by: Jan Beulich
---
V5:
From: Shuai Ruan
This patchset contain two xsaves bug fix patches
1. calculate the comp_offsets base on xcomp_bv
2. fix overwriting between non-lazy/lazy xsaves
Shuai Ruan (2):
x86/xsaves: calculate the comp_offsets base on xcomp_bv
x86/xsaves: fix overwriting between non-lazy/lazy xsaves
On March 18, 2016 5:49pm, wrote:
> >>> On 18.03.16 at 10:38, wrote:
> > On Fri, 2016-03-18 at 03:29 -0600, Jan Beulich wrote:
> >> >
> >> Not sure what exactly you're asking for: As said, we first need to
> >> settle on an abstract model. Do we want IOMMU mapping failures to be
> >> fatal to the
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 24 March 2016 07:52
> To: xen-devel
> Cc: Andrew Cooper
> Subject: Re: [Xen-devel] x86/vMSI-X emulation issue
>
> >>> On 23.03.16 at 18:05, wrote:
> > All,
> >
> > so I've ju
>>> On 24.03.16 at 03:37, wrote:
>> > --- a/xen/xsm/flask/hooks.c
>> > +++ b/xen/xsm/flask/hooks.c
>> > @@ -1658,6 +1658,40 @@ static int flask_xen_version (uint32_t op)
>> > }
>> > }
>> >
>> > +static int flask_version_op (uint32_t op)
>> > +{
>> > +u32 dsid = domain_sid(current->doma
>>> On 24.03.16 at 03:49, wrote:
>> > --- a/xen/common/symbols.c
>> > +++ b/xen/common/symbols.c
>> > @@ -17,6 +17,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> > #include
>> > #include
>> >
>> > @@ -97,8 +98,7 @@ static unsigned int get_symbol_offset(unsigned long
flight 87050 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 3 host-install(3) broken REGR. vs. 86629
test-armhf-armhf-
>>> On 24.03.16 at 04:13, wrote:
> On Wed, Mar 23, 2016 at 07:51:29AM -0600, Jan Beulich wrote:
>> >>> On 15.03.16 at 18:56, wrote:
>> And then of course the EXPERT question comes up again. No
>> matter that IanC is no longer around to help with the
>> argumentation, the point he has been making
>>> On 24.03.16 at 04:15, wrote:
> +### XEN_SYSCTL_XSPLICE_LIST (2)
> +
> +Retrieve an array of abbreviated status and names of payloads that are
> loaded in the
> +hypervisor.
> +
> +The caller provides:
> +
> + * `version`. Version of the payload. Caller should re-use the field
> provided by
>
>>> On 24.03.16 at 10:09, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
>> Beulich
>> Sent: 24 March 2016 07:52
>> > 2) Do aforementioned chopping automatically on seeing
>> > X86EMUL_UNHANDLEABLE, on the basis that the .check
>> > handler had indicate
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 March 2016 09:35
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel
> Subject: RE: [Xen-devel] x86/vMSI-X emulation issue
>
> >>> On 24.03.16 at 10:09, wrote:
> >> From: Xen-devel [mailto:xen-devel-boun...@lists
>>> On 23.03.16 at 18:36, wrote:
> On 21/03/16 14:22, Jan Beulich wrote:
> On 18.03.16 at 20:04, wrote:
>>> --- a/xen/include/xen/sched-if.h
>>> +++ b/xen/include/xen/sched-if.h
>>> @@ -9,6 +9,7 @@
>>> #define __XEN_SCHED_IF_H__
>>>
>>> #include
>>> +#include
>>>
>>> /* A global poin
>>> On 24.03.16 at 10:39, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 24 March 2016 09:35
>> To: Paul Durrant
>> Cc: Andrew Cooper; xen-devel
>> Subject: RE: [Xen-devel] x86/vMSI-X emulation issue
>>
>> >>> On 24.03.16 at 10:09, wrote:
>> >> Fro
On Wed, Mar 23, 2016 at 9:46 PM, Sarah Newman wrote:
> On 03/22/2016 11:03 PM, Sarah Newman wrote:
>> And nested xen.
>>
>> CPU: AMD Opteron 2352
>> Outer configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux
>> 3.18.25-18.el6.x86_64
>> Inner configuration: Xen4CentOS 6 xen 4.6.1-2.el6, linux
>> 3.
>>> On 24.03.16 at 10:02, wrote:
> On March 18, 2016 5:49pm, wrote:
>> That was taking only the flush timeout as an error source into account.
>> Now that we see that the lack of error handling pre-exists, we can't just
>> extend
>> that intended model to also cover those other error reasons wit
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 March 2016 09:47
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel
> Subject: RE: [Xen-devel] x86/vMSI-X emulation issue
>
> >>> On 24.03.16 at 10:39, wrote:
> >> -Original Message-
> >> From: Jan Beul
I have managed to compile Xen, the kernel, COLO, following the
information in this thread.
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03507.html
Github branche : changlox/colo_v12
https://github.com/Pating/xen/tree/changlox/colo_v12
Xen (COLO version) is now compiled and ins
On 23/03/16 19:03, Juergen Gross wrote:
> On 23/03/16 12:25, Andrew Cooper wrote:
>> On 23/03/16 11:18, David Vrabel wrote:
>>> On 23/03/16 11:12, Andrew Cooper wrote:
On 23/03/16 10:59, David Vrabel wrote:
> On 23/03/16 10:55, Andrew Cooper wrote:
>> On 23/03/16 10:52, Juergen Gross w
>>> On 23.03.16 at 17:36, wrote:
> Most patches do now how Acks/Reviews. The remaining patches are #1 (Rest),
> #6-8,11-13,18 (x86), #20 (ARM), 26 (Toolstack).
#20 doesn't have anything ARM specific, it's pure tools stuff.
Jan
___
Xen-devel mailing
On 24/03/16 10:27, Jan Beulich wrote:
On 23.03.16 at 17:36, wrote:
>> Most patches do now how Acks/Reviews. The remaining patches are #1 (Rest),
>> #6-8,11-13,18 (x86), #20 (ARM), 26 (Toolstack).
> #20 doesn't have anything ARM specific, it's pure tools stuff.
It is trying to fix a pointer
>>> On 24.03.16 at 06:57, wrote:
> **NOTE**
>This patch set should base on 2 prereq patch sets:
> a). Make the pcidevs_lock a recursive one.
This one already went in, so is pointless to mention here.
> b). Check VT-d Device-TLB flush error.
And this one is WIP, so it's continuing to
On 24/03/16 11:22, David Vrabel wrote:
> On 23/03/16 19:03, Juergen Gross wrote:
>> On 23/03/16 12:25, Andrew Cooper wrote:
>>> On 23/03/16 11:18, David Vrabel wrote:
On 23/03/16 11:12, Andrew Cooper wrote:
> On 23/03/16 10:59, David Vrabel wrote:
>> On 23/03/16 10:55, Andrew Cooper wr
On Wed, 23 Mar 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 22/02/16 17:38, Stefano Stabellini wrote:
> > On Fri, 15 Jan 2016, Ian Campbell wrote:
> >
> > I read the patch and looks good to me. You can add my
> >
> > Reviewed-by: Stefano Stabellini
> >
> > I have a couple of minor comments,
On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
>
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1532,6 +1532,13 @@ Note that if **watchdog** option is also
> specified vpmu will be turned off.
> As the virtualisation is not 100% safe, don't use th
Hi Everyone,
On Mon, Mar 21, 2016 at 3:42 PM, Dushyant Behl
wrote:
> Hi Julien,
>
> On Fri, Mar 18, 2016 at 10:53 PM, Julien Grall wrote:
>>
>>
>> On 18/03/16 15:01, Dushyant Behl wrote:
>>>
>>> Hi Julien,
>>
>>
>> Hi Dushyant,
>>
>>> On Thu, Mar 17, 2016 at 8:22 PM, Julien Grall
>>> wrote:
>>>
On March 24, 2016 6:33pm, Jan Beulich wrote:
> >>> On 24.03.16 at 06:57, wrote:
> > **NOTE**
> >This patch set should base on 2 prereq patch sets:
> > a). Make the pcidevs_lock a recursive one.
>
> This one already went in, so is pointless to mention here.
Agreed,
>
> > b). Check
(CC committers)
On 24/03/16 10:54, Stefano Stabellini wrote:
On Wed, 23 Mar 2016, Julien Grall wrote:
Hi Stefano,
On 22/02/16 17:38, Stefano Stabellini wrote:
On Fri, 15 Jan 2016, Ian Campbell wrote:
I read the patch and looks good to me. You can add my
Reviewed-by: Stefano Stabellini
I h
The patches are really independent, and the latter two are just
cleaning up code to make it easier to see all relevant uses of
X86EMUL_UNHANDLEABLE (dealing with which is the primary subject
of the first one).
1: HVM: fix forwarding of internally cached requests
2: vLAPIC: vlapic_reg_write() can't
On 24/03/16 10:58, Juergen Gross wrote:
> I've searched a little bit in git history in order to understand why
> xen-detect has been invented and/or has all the options which clearly
> are meant to be used in scripts.
>
> The last large modification was done in 2009 and I think Konrad is to
> blame
>>> On 24.03.16 at 12:12, wrote:
> (CC committers)
>
> On 24/03/16 10:54, Stefano Stabellini wrote:
>> On Wed, 23 Mar 2016, Julien Grall wrote:
>>> Hi Stefano,
>>>
>>> On 22/02/16 17:38, Stefano Stabellini wrote:
On Fri, 15 Jan 2016, Ian Campbell wrote:
I read the patch and looks g
Forwarding entire batches to the device model when an individual
iteration of them got rejected by internal device emulation handlers
with X86EMUL_UNHANDLEABLE is wrong: The device model would then handle
all iterations, without the internal handler getting to see any past
the one it returned failu
On March 24, 2016 7:04pm, wrote:
> On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> >
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1532,6 +1532,13 @@ Note that if **watchdog** option is also
> > specified vpmu will be turned off.
> > As th
It only ever returns X86EMUL_OKAY, so to make this more obvious change
the function return type to void. Re-structure vlapic_apicv_write() at
once to have only a single path leading to vlapic_reg_write().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
There's no point in forwarding these to the device model.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -217,36 +217,30 @@ static int handle_pmt_io(
struct vcpu *v = current;
PMTState *s = &v->domain->arch.hvm_domain.pl_time->vpmt;
-
Recursive locks know their current owner, and since we use the function
solely to determine whether a particular lock is being held by the
current CPU (which so far has been an imprecise check), make actually
check the owner for recusrively acquired locks.
Signed-off-by: Jan Beulich
--- a/xen/co
On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
wrote:
> On 24/03/16 10:58, Juergen Gross wrote:
>> I've searched a little bit in git history in order to understand why
>> xen-detect has been invented and/or has all the options which clearly
>> are meant to be used in scripts.
>>
>> The last large
On Thu, Mar 24, 2016 at 03:15:25AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 03:37, wrote:
> >> > --- a/xen/xsm/flask/hooks.c
> >> > +++ b/xen/xsm/flask/hooks.c
> >> > @@ -1658,6 +1658,40 @@ static int flask_xen_version (uint32_t op)
> >> > }
> >> > }
> >> >
> >> > +static int flask_v
flight 87093 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87093/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 4 host-install/dst_host(4) broken REGR. vs. 86491
test-amd64-i386-xl-q
Hi Jan,
On 24/03/16 11:28, Jan Beulich wrote:
On 24.03.16 at 12:12, wrote:
(CC committers)
On 24/03/16 10:54, Stefano Stabellini wrote:
On Wed, 23 Mar 2016, Julien Grall wrote:
Hi Stefano,
On 22/02/16 17:38, Stefano Stabellini wrote:
On Fri, 15 Jan 2016, Ian Campbell wrote:
I read the pa
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 March 2016 11:29
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant; Chang Jianzhong; Keir (Xen.org)
> Subject: [PATCH 1/3] x86/HVM: fix forwarding of internally cached requests
>
> Forwarding entire batches to t
>>> On 24.03.16 at 12:49, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 24 March 2016 11:29
>> --- a/xen/arch/x86/hvm/intercept.c
>> +++ b/xen/arch/x86/hvm/intercept.c
>> @@ -148,7 +148,7 @@ int hvm_process_io_intercept(const struc
>> ASSERT_UNREACHABLE();
>>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 March 2016 12:02
> To: Paul Durrant
> Cc: Andrew Cooper; Chang Jianzhong; xen-devel; Keir (Xen.org)
> Subject: RE: [PATCH 1/3] x86/HVM: fix forwarding of internally cached
> requests
>
> >>> On 24.03.16 at 12:49
On 18/03/16 19:05, Dario Faggioli wrote:
> by using the sched_switch hook that we have introduced in
> the various schedulers.
>
> The key is to let the actual switch of scheduler and the
> remapping of the scheduler lock for the CPU (if necessary)
> happen together (in the same critical section)
On Tue, 22 Mar 2016, Shanker Donthineni wrote:
> On 03/22/2016 05:21 PM, Julien Grall wrote:
> > (CC some ARM folks)
> >
> > On 21/03/2016 23:18, Shanker Donthineni wrote:
> >> Hi Julien,
> >
> > Hello Shanker,
> >
> > Sorry for the late answer.
> >
> >> Do you have any other comments to be address
On 18/03/16 19:05, Dario Faggioli wrote:
> From: Uma Sharma
>
> and, while we are adjusting signedness of opt_load_window_shift,
> make also prv->load_window_shift unsigned, as approapriate.
>
> Signed-off-by: Uma Sharma
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
> ---
> Cc: Ge
On Thu, 17 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen
> ACPI on ARM64 design document could be found from [1].
>
> This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI
> information. Introduc
On 18/03/16 19:05, Dario Faggioli wrote:
> The credit2 scheduler tries to setup runqueues in such
> a way that there is one of them per each socket. However,
> that does not work. The issue is described in bug #36
> "credit2 only uses one runqueue instead of one runq per
> socket" (http://bugs.xenp
On Wed, 16 Mar 2016, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 16, 2016 at 04:34:19PM +, Julien Grall wrote:
> > Hi Konrad,
> >
> > On 04/03/2016 21:19, Konrad Rzeszutek Wilk wrote:
> > >Anyhow what I am wondering if there are some semantincs when it comes to
> > >PPI
> > >and it being able
On Thu, 17 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> These tables are aligned with 64bit.
>
> Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
> xen/arch/arm/acpi/lib.c| 15 +++
> xen/include/asm-arm/acpi.h | 2 ++
> 2 files changed, 17 insertions(+
On 18/03/16 19:05, Dario Faggioli wrote:
> In fact, credit2 uses CPU topology to decide how to arrange
> its internal runqueues. Before this change, only 'one runqueue
> per socket' was allowed. However, experiments have shown that,
> for instance, having one runqueue per physical core improves
> p
On Thu, 17 Mar 2016, Shannon Zhao 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.
>
On 18/03/16 19:05, Dario Faggioli wrote:
> Experiments have shown that arranging the scheduing
> runqueues on a per-core basis yields better results,
> in most cases.
>
> Such evaluation has been done, for the first time,
> by Uma Sharma, during her participation to OPW. Some
> of the results she
On Thu, 17 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
Reviewed-by: Stefano Stabellini
On Thu, 17 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.
>
> Signe
On 18/03/16 19:27, Andrew Cooper wrote:
> On 18/03/16 19:06, Dario Faggioli wrote:
>> like what's there already in both Credit1 and RTDS. In
>> fact, when playing with affinity, a lot of cpumask
>> manipulation is necessary, inside of various functions.
>>
>> To avoid having a lot of cpumask_var_t
On Tue, 22 Mar 2016, Julien Grall wrote:
> Hi Shannon,
>
> On 17/03/16 09:41, 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
> > ---
> > v6: use SZ_64K for GICv3
>>> On 24.03.16 at 12:49, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 24 March 2016 11:29
>> @@ -196,8 +196,22 @@ int hvm_process_io_intercept(const struc
>> }
>> }
>>
>> -if ( i != 0 && rc == X86EMUL_UNHANDLEABLE )
>> +if ( unlikely(rc < 0) )
>>
On 24/03/16 12:44, George Dunlap wrote:
> On 18/03/16 19:27, Andrew Cooper wrote:
>> On 18/03/16 19:06, Dario Faggioli wrote:
>>> like what's there already in both Credit1 and RTDS. In
>>> fact, when playing with affinity, a lot of cpumask
>>> manipulation is necessary, inside of various functions.
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 March 2016 12:52
> To: Paul Durrant
> Cc: Andrew Cooper; Chang Jianzhong; xen-devel; Keir (Xen.org)
> Subject: RE: [PATCH 1/3] x86/HVM: fix forwarding of internally cached
> requests
>
> >>> On 24.03.16 at 12:49
flight 87134 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87134/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-sav
On Thu, 2016-03-24 at 12:44 +, George Dunlap wrote:
> On 18/03/16 19:27, Andrew Cooper wrote:
> > This avoids all this opencoded allocation/refcounting, the chance
> > that
> > starting a scheduler would fail for memory reasons, and one extra
> > cpumask in the per-cpu data area won't break the
On Thu, 2016-03-24 at 03:43 -0600, Jan Beulich wrote:
> > > > On 23.03.16 at 18:36, wrote:
> >
> > But of course that means files like sched_arinc653.c and
> > sched_credit2.c
> > end up including xen/err.c even though they don't use those macros.
> > Would you prefer the other files include it d
On Wed, 2016-03-23 at 17:51 +, George Dunlap wrote:
> On 18/03/16 19:04, Dario Faggioli wrote:
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -542,16 +542,11 @@ csched_alloc_pdata(const struct scheduler
> > *ops, int cpu)
> > }
> >
> > static void
> > -csched
On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> For consistency, we wrap a _sync version for all VT-d flush
> interfaces.
>
I'm sorry, maybe it's me, but "for consistency" with what?
I see from where this comes, if I look at v7. But when this patch will
be committed, what it is doing and why w
Hello, I've CC COLO authors for you.
Please be aware that COLO is still under development -- the interfaces
aren't stable yet.
On Thu, Mar 24, 2016 at 11:22:33AM +0100, Alexis RIES wrote:
> I have managed to compile Xen, the kernel, COLO, following the information
> in this thread.
> http://lists
Jim Fehlig writes ("[Xen-devel] [PATCH] tools: Restrict configuration of qemu
processes"):
> Commit 6ef823fd added '-nodefaults' to the qemu args created by
> libxl, which is a good step in restricting qemu's default
> configuration. This change takes another step by adding
> -no-user-config, whic
>>> On 18.03.16 at 11:32, wrote:
> @@ -278,6 +281,53 @@ static void teardown_apic_assist(struct vcpu *v)
> put_page_and_type(page);
> }
>
> +void viridian_start_apic_assist(struct vcpu *v, int vector)
> +{
> +uint32_t *va = v->arch.hvm_vcpu.viridian.apic_assist.va;
> +
> +if ( !va
On 24/03/16 11:29, Jan Beulich wrote:
> It only ever returns X86EMUL_OKAY, so to make this more obvious change
> the function return type to void. Re-structure vlapic_apicv_write() at
> once to have only a single path leading to vlapic_reg_write().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andr
On Tue, Mar 22, 2016 at 08:36:21AM +0100, Juergen Gross wrote:
> Committers,
>
> anything missing on my side to have this series being committed?
> All patches have Acked-by and Reviewed-by tags.
>
Can you provide a branch with all the tags folded in?
Wei.
_
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 March 2016 13:51
> To: Paul Durrant
> Cc: Andrew Cooper; Wei Liu; Ian Jackson; Stefano Stabellini; xen-
> de...@lists.xenproject.org; Keir (Xen.org)
> Subject: Re: [PATCH v6] x86/hvm/viridian: Enable APIC assist
>>> On 23.03.16 at 17:36, wrote:
> --- /dev/null
> +++ b/xen/include/asm-x86/cpufeatureset.h
> @@ -0,0 +1,32 @@
> +#ifndef __XEN_X86_CPUFEATURESET_H__
> +#define __XEN_X86_CPUFEATURESET_H__
> +
> +#ifndef __ASSEMBLY__
> +
> +#define XEN_CPUFEATURE(name, value) X86_FEATURE_##name = value,
> +enum {
On 24/03/16 11:30, Jan Beulich wrote:
> There's no point in forwarding these to the device model.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On March 24, 2016 5:59pm, wrote:
> >>> On 24.03.16 at 10:02, wrote:
> > On March 18, 2016 5:49pm, wrote:
> >3. For iommu_{,un}map_page(), we'd better fix it as a normal error,
> > as the error is not only from iommu flush, .e.g, '-ENOMEM'.
> > So, we need to {,un}map from the IOMMU, r
On Wed, Mar 23, 2016 at 06:21:58PM -0600, Jim Fehlig wrote:
> On 03/23/2016 09:27 AM, osstest service owner wrote:
> > flight 87014 ovmf real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/87014/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > includin
On 24/03/16 14:08, Jan Beulich wrote:
On 23.03.16 at 17:36, wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-x86/cpufeatureset.h
>> @@ -0,0 +1,32 @@
>> +#ifndef __XEN_X86_CPUFEATURESET_H__
>> +#define __XEN_X86_CPUFEATURESET_H__
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +#define XEN_CPUFEATURE(na
>>> On 24.03.16 at 15:12, wrote:
> On 24/03/16 14:08, Jan Beulich wrote:
>> Independently - is the asm() indeed unconditionally necessary?
>
> Yes. Otherwise alternative blocks in C fail to compile. They
> __stringify() the feature name, which used to turn into a number (when
> the feature was
On Thu, 2016-03-24 at 05:30 -0600, Jan Beulich wrote:
> Recursive locks know their current owner, and since we use the
> function
> solely to determine whether a particular lock is being held by the
> current CPU (which so far has been an imprecise check), make actually
> check the owner for recusr
They're not really useful past the building stage and only needlessly
increase binary file sizes.
Signed-off-by: Jan Beulich
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -50,6 +50,7 @@ ALL_OBJS-$(CONFIG_X86) += $(BASEDIR)/c
CFLAGS += -nostdinc -fno-builtin -fno-common
CFLAGS += -Werror -Wredunda
On 24/03/16 11:30, Jan Beulich wrote:
> Recursive locks know their current owner, and since we use the function
> solely to determine whether a particular lock is being held by the
> current CPU (which so far has been an imprecise check), make actually
> check the owner for recusrively acquired loc
On 24/03/16 14:31, Jan Beulich wrote:
> They're not really useful past the building stage and only needlessly
> increase binary file sizes.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
ht
On 24/03/16 14:33, Jan Beulich wrote:
> This wasn't a good idea after all - make them unavailable except for
> legacy code using an older interface version.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel
Changlong Xie writes ("[PATCH v12 11/26] tools/libxl: add back channel support
to read stream"):
> From: Wen Congyang
>
> This is used by primay to read records sent by secondary.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.
On 2016年03月23日 00:16, Julien Grall wrote:
> Hi Shannon,
>
> On 22/03/16 13:18, Shannon Zhao wrote:
>> On 2016年03月22日 08:42, Julien Grall wrote:
>>> Hi Shannon,
>>>
>>> On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Map the UEFI and ACPI tables which we created to non-R
>>> On 24.03.16 at 15:12, wrote:
> On March 24, 2016 5:59pm, wrote:
>> >>> On 24.03.16 at 10:02, wrote:
>> > On March 18, 2016 5:49pm, wrote:
>
>
>> >3. For iommu_{,un}map_page(), we'd better fix it as a normal error,
>> > as the error is not only from iommu flush, .e.g, '-ENOMEM'.
>> >
Changlong Xie writes ("[PATCH v12 08/26] libxc/migration: Specification update
for DIRTY_PFN_LIST records"):
> From: Wen Congyang
>
> Used by secondary to send it's dirty bitmap to primary under COLO.
Thanks. In response to some of the previous patches I wrote:
I think this will want a rev
Changlong Xie writes ("[PATCH v12 07/26] docs/libxl: Introduce
CHECKPOINT_CONTEXT to support migration v2 colo streams"):
> From: Wen Congyang
Thanks for the additional information in the comments.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xe
Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.
Rename it to xen_xlate_map_ballooned_pages.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
---
arch/x86/xen/grant-table.c | 57 +--
drivers/xen/
Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.
Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
---
arch/arm/xen/enlighten.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
On Thu, 2016-03-24 at 14:56 +0100, Dario Faggioli wrote:
> On Thu, 2016-03-24 at 13:57 +0800, Quan Xu wrote:
> >
> > @@ -134,8 +133,8 @@ int dev_invalidate_iotlb(struct iommu *iommu,
> > u16
> > did,
> > /* invalidate all translations:
> > sbit=1,bit_63=0,bit[62:12]=1 */
> >
Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.
CC: Rob Herring
Signed-off-by: Shannon Zhao
Acked-by: Rob Herring
Reviewed-by: Stefano Stabellini
---
Documentation/devicetree/bindings/arm/xen.txt | 33 +++
Add a new type of Xen map space for Dom0 to map device's MMIO region.
Signed-off-by: Shannon Zhao
---
include/xen/interface/memory.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen
Changlong Xie writes ("[PATCH v12 15/26] libxc/restore: support COLO restore"):
> 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 con
This new delivery type which is for ARM shares the same value with
HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86.
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).
Signed
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.
CC: "Rafael J. Wysocki" (supporter:ACPI)
CC: Len Brown (supporter:ACPI)
CC: linux-a...@vger.kerne
Changlong Xie writes ("[PATCH v12 16/26] libxc/save: support COLO save"):
> From: Wen Congyang
>
> After suspend primary vm, get dirty bitmap on secondary vm,
> and send pages both dirty on primary/secondary to secondary.
Acked-by: Ian Jackson
___
Xe
flight 87117 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/87117/
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
Changlong Xie writes ("[PATCH v12 12/26] secondary vm suspend/resume/checkpoint
code"):
> From: Wen Congyang
Thanks.
This is all fine except for one small thing:
>
> +/* COLO only supports HVM now because it does not work very
> + * well with pv drivers:
> + * 1. We need to resume
When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
---
arch/arm/xen/enlighten.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm/x
1 - 100 of 281 matches
Mail list logo
